Das zweite Leben der chinesischen Wunderspitze J2534 / Sudo Null IT News

Vor langer Zeit, als die Bäume groß waren und die Variationen der Konfigurationen eines Automodells mit den Fingern einer Hand aufgelistet werden konnten, wurde ein Diagnoseadapter gekauft, der heute besprochen wird. Die Kreation eines unbekannten Chinesen hieß Mini-VCI J2534. Woher es kam, ist nicht sicher bekannt, aber es ist als Schnittstelle für die Arbeit mit verschiedenen Toyotas sowie als J2534-kompatibler Adapter (Spoiler – nein) positioniert. Zum Zeitpunkt des Kaufs reichte es aus, die Autos jener Jahre zu diagnostizieren und in den Köpfen der Autos zu pflücken, aber der Fortschritt steht nicht still und in den aktuellen Realitäten, wenn ich so sagen darf, „nimmt er nicht heraus“. Ob dagegen etwas unternommen werden kann, wird weiter unten diskutiert.

Also, lernen Sie uns kennen – unsere Patienten von außen und von innen:

Achten Sie auf die Kennzeichnung des Mikrocontrollers LPC2119, wir kommen später darauf zurück.Achten Sie auf die Kennzeichnung des Mikrocontrollers LPC2119, wir kommen später darauf zurück.

Im Inneren lebt eine 16/32-Bit-ARM7TDMI-S ™ -CPU, ein paar CAN-Controller, 2 UARTs und ein Haufen nützlicher und nicht sehr praktischer Peripheriegeräte.

Die Essenz des Problems

Verschließt man die Kleinigkeiten in Form einer fast vollständigen Nichteinhaltung des J2534-Standards, hat es weitaus schlimmere Probleme, nämlich die Unfähigkeit, Daten länger als ~48 Bytes über das ISO-TP-Protokoll zu senden. Letzteres konnte ich nicht ertragen, und in meinem Kopf setzte sich der Gedanke fest, was wäre, wenn sich herausstellte, dass es diese Welt ein wenig besser macht.

Kurz gesagt, wie ist die Übertragung von Daten länger als 8 Byte auf dem CAN-Bus (die Länge der CAN-Nachricht ist auf acht Byte begrenzt). Es gibt einen solchen Standard ISO15765, auch bekannt als ISO-TP (Transport Protocol), der 2 OSI-Modelle (Netzwerk und Transport) abdeckt. Die Übertragung von Daten, die länger als 7 Bytes sind, sieht folgendermaßen aus:

  1. Die Quelle sendet einen First Frame (FF) mit Angaben zur Gesamtlänge der übertragenen Daten und den ersten 6 Bytes der Payload.

  2. Der Empfänger antwortet darauf mit einem Flow Control-Frame, in dem er über die minimal zulässige Zeit zwischen dem Senden von CFs (darüber weiter unten) und die Anzahl der CFs spricht, nach der die Quelle erneut auf den Flow Control-Frame warten muss.

  3. Nach Erhalt der Flusskontrolle sendet die Quelle weiterhin Daten in Consecutive Frame (CF)-Frames mit einem festgelegten Intervall und wartet auf die nächste Flusskontrolle (falls dies in Absatz 2 erwähnt wurde).

    https://en.wikipedia.org/wiki/ISO_15765-2

Was wirklich passiert und warum nichts funktioniert, hilft uns der übliche CAN-Bus-Analysator (Can Hacker / PEAK CAN und ähnliche) herauszufinden. Also, Ölmalerei – alles ist durcheinander, Pferde, Menschen. Der Empfänger sagte, warte alle 8 aufeinanderfolgenden Frames der Flusssteuerung von mir und schickte mir jeden aufeinanderfolgenden Frame mindestens 10 ms später, und das Kabel ignorierte nicht nur das FC-Warten, sondern achtete auch nicht auf die Mindestverzögerung zwischen CFs.

Flusssteuerung vom Empfänger – 30 08 0A FFFFFFFFFF, wobei 08 die Anzahl von CFs ist, nach denen die Quelle erneut auf einen Flusssteuerungsrahmen warten muss, 0A die minimal zulässige Zeit zwischen dem Senden von CFs ist.

Was wir tatsächlich haben, ist eine Verzögerung von etwa 1 ms zwischen den CFs anstelle der gewünschten 10 ms und kein Warten auf Flow Control, was den gesamten Übertragungsprozess vollständig unterbricht.

Okay, denken Sie nur, organisieren wir unser ISO-TP mit Verzögerungen und Timings, da Sie mit dem Kabel mit rohen CAN-Daten arbeiten und sehen können, was passiert ist (was für eine ekelhafte Sache).

Das Schlüsselband verwendet den FT232 USB-UART-Konverter, der einige Probleme bei der Arbeit mit USB 3.0 hat. Und diese Probleme sind Pferdeverzögerungen, die nicht vom Treiber konfiguriert werden, obwohl alles auf USB 2.0 funktioniert, aber wo kann man jetzt einen ehrlichen USB 2.0-Controller in einer Mutter / einem Laptop finden. Generell entfällt auch die manuelle Formatierung, Verzögerungen zwischen CFs sind nicht zu bemängeln, das wird auch nicht funktionieren.

Es bleibt eine extreme Maßnahme – hineinzuklettern und zu versuchen, die krumme Software möglichst mit Krücken zu reparieren. Ich weiß nicht wie, aber direkt über USB vom Controller aus können Sie Flash-Speicher lesen und schreiben, auch ohne das Kabel mit dem Programm zu demontieren Blitzzauber. Nach dem Lesen laden wir die Firmware in IDA, die ARM-Little-Endian-Prozessor-ARMv4T-Architektur. Ein wenig Nachhilfe mit den Händen, Erstellen der fehlenden Regionen und die Firmware ist bereit für die Recherche.

Die Funktion mit der Implementierung des Sendens von Daten über ISO-TP wurde von der Rückseite gefunden (CAN-Peripherie – Senden – Wrapper – die Funktion selbst). Was die Quellen betrifft – hier ist ein Stück Code mit Sendedaten. Was oben gesagt wurde, ist überhaupt nicht vorgesehen.

iso_tp_fc_received_ptr = &ctx->iso_tp_fc_received; while (sent_len < send_len) { if (ff_flag) { if (cf_counter >= 0xF) cf_counter = 0; sonst ++cf_counter; v21 = 8; tx_data.data[0] = cf_counter + 0x20; // Aufeinanderfolgende Frames erstellen v23 = v21 – 1; if (send_len – sented_len < v21 - 1) v23 = send_len - sented_len; memcpy(&tx_data.data[1]&schicke Daten_[sended_len], v23); can_tx_1(ctx, &tx_data); sent_len += v23; } Else {tx_data.data[0] = 0x10; // Assembly Erster Frame tx_data.data[1] = send_len; // Mehr als 255 Bytes werden nicht bereitgestellt, obwohl es laut Standard 4 kb mit Kopeken sein sollten, obwohl ich von memcpy(&tx_data.data[2], send_data_, 6)); cf_counter = 0; set0 (iso_tp_fc_received_ptr); can_tx_1(ctx, &tx_data); if (!wait_fc(ctx, 700)) // Auf Ablaufsteuerung warten return 0; ff_flag = 1; send_len += 6; } }

Wie Sie sehen können, wartet die Flow Control-Spitze nur einmal und versucht dann nicht einmal, ISO-TP einzuhalten. Sobald er den FC erhält, beginnt er sofort damit, die restlichen Daten ohne Verzögerung in Consecutive Frames zu senden. Okay, aber vielleicht achtet er wenigstens auf die Daten der Flow Control? Ha ha. Nein. Hier ist die ISO-TP-Datenempfangsverarbeitungsfunktion, wir interessieren uns nur für den Flusssteuerungsempfang.

Header = rx_byte_0 & 0xF0; if (can_rx_ctx->rx_can_data[0] & 0xF0) { switch (header) { //Es gab Handler für andere Header, aber wir brauchen sie nicht case 0x30: //Flow control set_1(&iso_tp_ctx->iso_tp_fc_received); Ergebnis = 0; Unterbrechung; } }

Wie Sie sehen, wird einfach ein Flag gesetzt, dass eine Art Flusskontrolle akzeptiert wurde, und was darin steht, ist uns nicht wichtig (chinesische Gedanken).

Was zu tun ist?

Günstig und fröhlich – Legen Sie eine einfache Verzögerung zwischen dem Senden aufeinanderfolgender Frames fest, damit der Empfänger Zeit hat, seine Flusssteuerung dorthin zu senden, wo sie benötigt wird, und danach die nächste CF zu empfangen. Wir müssen lediglich eine Stelle in der Dispatch-Schleife finden, an der wir den Übergang in eine Funktion mit Verzögerung setzen können, da es viele solcher Stellen gibt und die ersetzten Anweisungen in einer neuen Funktion ausgeführt werden können, also werden wir es nicht tun nichts verlieren. Wir nehmen IAR, es hat Unterstützung für einen solchen Prozessor, ein sauberes Assembler-Projekt und schreiben einen elementaren Zyklus

_my_func STMFD SP!, {R10-R12,LR} LDR R10, =39062 ; ~7800 für 1ms B vergleiche sub: SUB R10, R10, #1 vergleiche: CMP R10, #0 BGT sub MOV R0, R4 ; dieselbe ersetzte Anweisung zum Springen von LDMFD SP!, {R10-R12,PC}

Das Endergebnis sieht so aus – was links war, wurde rechts. MOV R0, R4-Befehl verschoben.

Wir flashen und genießen die hervorragende Arbeit ohne Ausfälle.

Natürlich war es möglich, alles nach Feng Shui zu machen, und die korrekte Verarbeitung des Flow Control-Frames und ehrliche Verzögerungen auf Wunsch des Empfängers und das Warten auf den Rest der Flow Controls. Aber das Ergebnis wird auf jeden Fall erreicht und es bleibt keine Zeit, mehr als einen Abend mit einem solchen Wunsch zu verschwenden.

Ein weiterer interessanter Punkt ist, dass der Controller eine chinesische Bemerkung zu sein scheint, weil. wurde vom Programm per interner ID als LPC2114 ermittelt, in dem laut Datenblatt für eine Minute gar kein CAN-Controller steckt. Siehst du CAN? Und ich sehe es nicht, aber es ist da. So ist das.

Wer hat Interesse Firmware und IDA-Basis, dann hier. Passwort habr.com

Similar Posts

Leave a Reply

Your email address will not be published.