PDC-Modul

Nachdem ich nun endlich mein BCM dazu bewegen konnte ein "Zündung ist an" Signal auf den MS-CAN zu legen, konnte ich auch das PAM weiter testen. Da noch nicht klar ist wie das PAM an die CCC kommt, habe ich das BCM mit angeschlossenem PAM reprogrammiert (Option "Parking aid front+rear") und die CAN-Nachrichten auf dem MS-CAN aufgezeichnet. Das muss ich mit Ruhe mal analysieren.

Zunächst aber die schlechte Nachricht: Beim Druck auf den PDC-Taster blinkt die PDC-LED immer noch. Also Störung, keine Funktion.

Die gute ist aber: Die Anzahl der DTCs hat sich deutlich reduziert!
Anfangs hatte ich noch all diese:

Nachdem ich die Sensoren richtig und vollständig dran hatte sind dann noch die DTCs vom hinteren Lautsprecher und diese beiden CAN-Kommunikationsfehler übrig geblieben:
U0140, 00, 2F => U0140: "Lost Communication With Body Control Module (GEM)", 00: "No sub type information", 2F: ???
U0422, 00, 2E => U0422: "Invalid Data Received from Body Control Module", 00: "No sub type information", 2E: ???

Jetzt, nach der Reprogrammierung hat sich das auf einen DTC reduziert:

U0422, 00, 2F => U0422: "Invalid Data Received from Body Control Module", 00: "No sub type information", 2F: ???
Der Unterschied im letzten Byte ist unklar, weil noch kein Mensch weiss was dieser letzte Wert im DTC bedeutet.

Die Meldung "Invalid Data Received from BCM" legt den Schluß nahe, das das PAM mit dem was da im BCM eingestellt wurde nicht klar kommt, oder nicht abrufen kann.

Der Mitschnitt des MS-CAN während der Programmierung des BCM ergab keinerlei erkennbare CAN IDs welche nicht auch ohne Programmiervorgang präsent wären. Entweder hat die Programmierung nicht geklappt, oder das BCM schreibt bestimmte Config-Werte ständig auf den Bus. Muss mal ausprogrammieren und nach Vorher/Nachher Interschieden IN den Paketen schauen. Auf meinen Laborbus ist ja relativ wenig Traffic.

Wieso glaubst Du das ein mit "BS7T" beginndendes Modul vom vFL sei?
"B" bedeutet doch "Erstmalig verwendet im Baujahr 2011".
Dennoch würd ich das gerne mal testen mit dem Update. Was braucht man dazu?

Zitat von BBG-AE185

ich hatte das Bild vom 1. Post gesehen, da ist ein 8G92... abgebildet. Für den Mondeo kenne ich nur die 7G92..., 8G92... und AG92... Das BS7T... stammt aus dem Galaxy, eventuell ist da was anders.

Das Bild aus dem ersten Post war nur als Beispiel gedacht (daher steht auch drüber "Hier mal exemplarisch eines"). Aber Deine Theorie vom Galaxy kann nicht stimmen, denn hier ein Bild aus meinem Mondeo, als ich letztens die RFK testete, ist das Modul gut zu erkennen und ganz klar BS7T:

Nur die letzten Buchstaben sind anders als die von meinem Testmodul.

Da gibt es ja doch immer das Thema mit den Ersatznummern, etc. Wie auch immer, man kann sich halt auf nix verlassen. Bin dennoch auf dem Tripp das da überall dasselbe drin steckt, zumindest als Hardware. Die Tage bekomme ich nich ein PDC Modul vom vFL.

Das PAM befindet sich ja im MS-CAN. Das BCM hat interfaces für HS- und MS-CAN. Aus irgend einem Grund ist es aber nur über den Hs-CAN programmierbar. Das wirkt als wäre hier sein "Primärinterface".

Ich hätte irgendwie beim programmieren erwartet das ich irgendwelche Pakete mit der Node-ID des PAM (0x736) zu sehen.

Könnte es sein, das für den Zugang zur CCC auf dem MS-CAN das IPC als eine Art Gateway zuständig ist?

Folgende Theorie habe hierzu:
Beim programmieren der Funktion wird ausschließlich die CCC geschrieben. Die Module selbst merken davon zunächst nichts.
Programmiere ich das BCM, geschieht dies ausschließlich über HS-CAN.
Am Ende des Vorganges wird ein globaler Modul-Reset ausgelöst (siehe CCC programmer thread). Dies veranlasst u.a. das PAM zu einem Neustart.
Beim Modulstart (Neustart) liest es die für das Modul notwendigen Parameter mittels Herstellerspezifischem OBD-Request vom BCM. Bei OBD-Requests wird, anders wie bei reinem CAN, über die Node-ID eine Zieladresse angegeben. Hiermit könnte das Modul gezielt beim BCM (Node-ID 0x726) anfragen. Damit das BCM weiss an wen die Antwort geht, schickt das PAM zuerst eine PID für die Rücksendeadresse, wo es seine ID angibt (0x736).

Wenn diese Theorie zutrifft, dann werden durch die BCM-Programmierung auch nur die am HS-CAN befindlichen Module resettet und auch nur diese ziehen sich dann ihre Parameter. Um dasselbe auf dem MS-CAN zu erledigen muss dann noch das IPC programmiert werden. Somit dürfte z.B. eine Änderung der PAM-Funktion (z.B. "keine" oder "nur hinten") keine Wirkung haben, wenn man diese nur ins BCM schreibt.

Update: Es lebt! vain

Ich habe in der früh noch schnell einen Test gemacht. Bislang hatte ich ja das Problem, das im PAM immer ein DTC U0422 gemeldet wurde (Kommunikation zum BCM gestört) und dadurch die PDC Funktion nicht startete (6mal blinken im PDC Taster).

Nachdem ich nun weiss das die CCC ständig über den CAN Bus übermittelt wird (siehe CAN Hacking Thread: CAN-Hacking) und in ihr die Funktionskodierung des PAM liegt, habe ich aus einer Aufzeichnung des MS-CAN im Ruhezustand mit Zündung vom Fahrzeug alle IDs bis auf die 400er entfernt. Dieses, reine CCC Logfile habe ich dann über meinen CAN Adapter von CANHacker in einer Loop abspielen lassen. Zu diesem Zeitpunkt hatte ich nur das PAM damit verbunden.

Anschließend habe ich das PAM resettet, die DTC gelöscht und voller Erwartung den Taster gedrückt. Und was soll ich sagen? Es funktionierte alles sofort! Kein weiterer DTC, ordentlich bekanntes gepiepe aus den Lautsprechern, weil die Sensoren einfach so auf dem Tisch rumliegen. Lies sich auch ohne Probleme wieder über den Taster deaktiveren, aktiveren, usw.

SOOO GEIL!!!

Damit ist jetzt nicht nur endgültig bewiesen wie das PAM seine Funktions-Programmierung erhält, sondern ich kann es auch völlig separat unter Laborbedingungen weiter testen. Zum Beispiel untersuche ich gerade die Signale der PDC Sensoren. Ich will ja immer noch einen Tester auf Arduino Basis dafür entwickeln, sodass man verlässlich Sensoren auf Funktion prüfen kann. Desweiteren sind das prima Spielzeuge für eigene Basteleien. So robust und günstig bekommt man nichts vergleichbares auf dem Markt. Ideal für Roboter oder sonstige Mess und Regelaufgaben. Ich habe z.B. vor damit eine Hindernisserkennung für mein elektrisches Garagentor zu realisieren, nachdem ich mir damit selbst einen üblen Schaden am Fahrzeug verursacht hatte...

Im weiteren möchte ich mich etwas dem Mikrocontroller und der Software des PAM-Moduls widmen. Wie auf den Fotos zuvor schon zu erkennen ist, werkelt im Modul ein NXP uController vom Typ "MC9S12DT128".

Hier habe ich angesetzt und mir das Datenblatt besorgt.

So ein Mikrocontroller ist eine Zusammenstellung von CPU, Speicher und Schnittstellenkomponenten in einem Gehäuse. Der MC9S12DT128 besteht laut Datenblatt aus einer 16-Bit CPU vom Typ HCS12 (dieser ist Opcode-Kompatibel mit den CPU-Typen 68HC11 und 68HC12). Dazu besitzt er noch 128kb Flash, 8kb RAM, 2kb EEPROM, jede Menge digitale und Analoge I/O-Ports, A/D-Wandler, parallele 8-Bit (BDLC) und serielle Schnittstellen (SCI, SPI), PWM-Kanäle, sowie 3 CAN-Controller, uvm. Hier ein Blockdiagramm des Chips:

Mich interessiert vor allem die CPU und der Flash. Im Flash steckt das Programm und die CPU führt es aus. Die Software kann also auch nur max. 128 kb groß sein kann. Über den CPU-Typ ist der Befehlssatz definiert. Auslesen kann man das nicht, dagegen ist der Chip gesichert. Man kann lediglich das Flash löschen und neue Software aufspielen. Das nennt man dann "Update" oder "Programmieren" oder "Flashen" Hierzu sendet man zunächst ein Stück Software zum Chip, den sog. "Bootloader". Die ist klein genug um in den Arbeitsspeicher (RAM) zu passen und dort ausgeführt zu werden. Die Übertragung geschieht über den CAN-Bus mit Hilfe von OBD2-Prozeduren und Datenpaketen. Nachdem der geladen ist, übernimmt er die Kontrolle über den Chip. Die Aufgabe des Bootloaders ist einfach: Bringe den Chip in den "Single-Chip" mode, lösche das Flash und empfange über den CAN-Bus die zu programmierende Software als Datenstrom. Schreibe diese ins Flash. Dazu noch ein paar Checksum-Routinen und ein Restart und das Update ist durch.

Man kann also wohl auch eine eigene Software senden, die der Chip dann ausführt. Die darf jedoch max. so groß wie das RAM (also 8kb) sein und ist nach einem Reboot wieder weg. Wollen wir etwas dauerhaft haben, müssen wir es ins Flash schreiben. Auf die Art könnte man also zur Laufzeit dem Modul eine ganz andere Funktion verpassen... hmmm, das werde ich mir merken, ist vielleicht mal von Nutzen.

Jetzt interessiert mich aber die Software des PAM selbst. Zunächst muss ich an diese ran kommen, was mir auch gelungen ist (wie, wird nicht verraten, da ich meine Quellen schützen möchte!). Ich habe nun also das binäre Abbild vom Flash, nennen wir es "Firmware". Hier steckt alles drin was das PAM kann. Als binärer Datenstrom wird man daraus aber nicht schlau. Um den Programmablauf zu verstehen muss man wieder Quellcode draus machen. Diesen Vorgang nennt man "Disassembe", also das Gegenteil von "Assemble" dem übersetzen von Quellcode in Maschinensprache. Disassembler braucht man normalerweise nur, wenn man den Quellcode verloren hat oder systeme hacken will. Letzteres will ich Die Quellcodesprache ist meist in eine Hochsprache wie "C". Im Datenblatt wird der Chip mit "C optimized architecture produces extremely compact code" beworben, was dies sehr wahrscheinlich macht!

Ich suche nun also einen Disassembler der in der Lage ist, aus dem Abbild für eine HCS12-CPU wieder Assemblercode zu generieren. Gelesen habe ich, das es solche Programme gibt die sogar Bibliotheken in dem Code erkennen. Es ist so, das eine Hochsprache wie z.B. "C" für bestimmte Funktionen (z.B. eine While-Schleife oder String-Verarbeitung) vorgefertigte Assemblerroutinen verwendet. Diese befinden sich in Bibliotheken und werden beim übersetzen des Programms (dem "compilieren") in den ausführbaren Programmcode mit eingebunden. Nach diesen Signaturen sucht der Disassembler und kann daraus dann wieder Rückschlüsse ziehen, in welcher Sprache das Programm ursprünglich mal erstellt wurde. Weiterhin kann er die Aufrufe rekonstruieren und somit möglichst viel echten Quellencode erzeugen. Auch untersucht er den Programmablauf um CPU-Befehle von Daten zu unterscheiden. Diese können nämlich überall im Datenstrom vorkommen.

Sobald ich weiss, welche Disassembler dazu in der Lage sind und ich sowas wie einen Quellcode daraus umwandeln kann, bin ich in der Lage den Programmablauf nachzuvollziehen. Grundsätzlich startet jedes Programm an einer definierten Speicherstelle, die von der CPU vorgegeben ist. Überhaupt läuft alles über Speicheradressen, auch das I/O. Grob muss man sich das so vorstellen: Will das Programm eine bestimmte I/O-Leitung von LOW auf HIGH setzen um damit z.B. eine LED anzusteuern, so schreibt es einen Bytewert an eine bestimmte Speicheradresse. An dieser ist jedoch kein Flash-Speicher, sondern es reagiert ein I/O-Chip darauf. Die Speicheradressen der Peripheriebausteine sind fest vorgegeben. Soetwas sieht dann so aus:

Ich hoffe das mich das irgendwann an den Punkt bringt, wo ich in der Lage bin den Programmcode zu verstehen und nach meinen Vorstellungen zu ändern. Eine Idee wäre, das PAM-Modul unter einer anderen CAN-ID zu betreiben um mit einem parallel am Bus hängenden Modul die CAN-Nachrichten nach belieben zu ändern und mit der richtigen ID wieder auf den Bus zu legen. Oder die Geschwindigkeitsabhängige Deaktivierung zu entfernen. Aber theoretisch könnte man auch eine ganz eigene Software erstellen die mit dem PAM garnichts zu tun hat und dieses dann nur als Programmspeicher dient. Natürlich unter Verlust der PAM-Funktion. Alles nur Ideen...