Mondeo MK4 BCM clonen

Hallo,

aus dem Thema "Funktion der RDKS" heraus ist dieses Projekt entstanden über das ich gerne hier im Fortschritt berichten möchte.

Nebenbei möchte ich einige Erkenntnisse über den Aufbau und die Firmware desselben erlangen, die wiederum in anderen Projekten oder Fragestellungen interessant sein können.

Das Ziel

Das Primärziel ist es ein BCM zu clonen. Darunter versteht man die Übertragung der "Daten" von einem BCM (Quelle) zu einem anderen (Ziel) sodass sich das geclonte BCM aus Sicht des Fahrzeugs nicht von dem original verbauten unterscheidet. Das ist in erster Linie für die darin befindlichen PATS-II Synchronisations/Schlüsselcodes wichtig. Passen diese nicht zu den anderen PATS-II Modulen im Fahrzeug (hinterlegt in PCM, ABS und ggf. KVM) verweigert die Wegfahrsperre den Motorstart bzw. das einschalten der Zündung.

Eine Neuprogrammierung der Schlüssel kann aktuell nur von Ford vorgenommen werden, da hierzu ein Online-Zugang erforderlich ist.

Will man also sein BCM aufgrund einer Hochrüstung oder eines Defekts austauschen, benötigt man eine Reprogrammierung der Schlüsselcodes (nicht der CCC, das geht noch einfach). Durch den "Clone" Vorgang wird dies überflüssig, da hier alles notwendige mit kommt.

Wie immer nervt es mich das es Hardware/Software und auch Service-Anbieter gibt die das schon lange ermöglichen, aber das genaue Verfahren natürlich geheim halten weil sie gut Kasse damit machen. Und so findet man dutzende sinnlose Videos und Infos im Netz die letztlich nur zeigen wie so ein Tuning-Buden-Honk mit einem ein- bis zweitausend Euro teuren Car-Programmierer und Spezialsoftware einen Clone herstellt.

Der Gegner

Das BCM vom vFL und FL unterscheidet sich grundlegend in der Architektur und Komponenten. Auch wenn davon auszugehen ist das die Funktionen der Firmware nahezu gleich sind, sind die Modelle nicht untereinander austauschbar.

Beim Mondeo FL gibt es verschiedene Modelle von BCMs (werden auch manchmal als GEM oder CEM bezeichnet), diese Unterscheiden sich hauptsächlich durch die Motorisierungs-Art (Benziner/Diesel) und zusätzlich noch dem Funktionsumfang (Bestückung von Komponenten auf der Platine) des Fahrzeugs (Xenon/Normal-Licht, usw.).

Hier beschäftige ich mich erstmal nur mit dem BCMii des FL, einem BG9T-14A073-XK

Geöffnet und von oben schaut es so aus:

Die Waffen

Div. Messgeräte, Informationen und eine gute Portion Erfahrung sowie Intuition. Hilfe von anderen nicht zu vergessen

Hinweis: Das hier ist ein Versuch, ohne genau zu wissen wohin es führt, ob ich am Ende Erfolg haben werde oder nicht!

P.S.: Ich habe dieses Thema geschlossen da ich es wie eine Art Blog verwenden werde und damit die Lesbarkeit erhalten bleibt. Kommentare bitte im Parallel-Thread: Kommentare zu "BCM clonen (Reverse Engineering)"

Mein Hauptinteresse liegt am Zentralprozessor auf dem Board. Dies ist ein Mikrocontroller von NEC (heute Renesas) vom Typ

R32C R5F64524KFD

Die lustigen Zahlen und Buchstaben bezeichnen die Variante. Damit ist meist die Größe des internen Flash, ggf. auch besonderer interner Funktionen und Temperaturfestigkeiten angegeben. Dieser Typ gehört aufgrund seiner Ausstattung und Chip-Größe zur Gruppe "152" (R32C/152).

Wie immer startet die Reise mit einer Suche nach einem passenden Datenblatt. Und zum Glück gibt es das frei verfügbar zum Download. Also erstmal den Inhalt (140 und 660 Seiten) reinziehen...

Aus dem Datenblatt geht schonmal hervor das sich in dieser MCU eine 32-Bit CISC CPU, 768k Flash (das Datenblatt sprich von "ROM" was aber irreführend ist) sowie 8k EEPROM befindet. Die CPU kann intern auf 48k RAM verfügen. Alles nicht üppig, macht aber das Reverse Engineering leichter

Dann interessiert mich wie eine solche MCU programmiert (geflasht) wird, denn das ist in der Regel auch der Weg in die andere Richtung. Das Datenblatt gibt dazu aus das diese MCUs über UART programmiert werden. "UART" bedeutet, es gibt einen Serial-Port und ein Protokoll mit dem man mit der MCU Kontakt aufnimmt. Bei anderen Chips wird das über JTAG, BDM, ISP, u.ä. gelöst. Beim UART ist es eine reine Software-Sache, es muss also im Chip einen "Booloader" geben der die UART bedient. Dieser Bootloader sollte fest im Chip (ROM) implementiert sein, damit er nicht durch einen Softwarefehler ausfallen und somit der Chip unbrauchbar werden kann. Ein solcher Bootloader ist auch bei anderen MCUs (z.b. dem allseits beliebten Arduino mit dem Atmega328) vorhanden. Er wirkt entweder immer beim Start des MCU, oder man muss ihn speziell aktivieren.

Achja, natürlich gibt es auch einen Schutz gegen unberechtigtes auslesen. Wie der aussieht und wirkt werde ich mir ansehen sobald ich mal Kontakt mit der MCU aufgenommen habe. Für UART benötigt man irgendeine serielle Schnittstelle. Ich nutze einen FTDI-Adapter für sowas. Der kommt ins USB und erzeugt mit dem Treiber einen virtuellen COM-Port in Windows. An diesen kann man sich dann per Software (Terminalprogramm oder eigene) dranhängen und was machen. Der FTDI kann noch viel mehr als RX/TX, man könnte auch Hilfssignale wie z.B. dem RESET o.ä. über ihn erzeugen. Wir werden sehen was notwendig ist...

Mein erstes Interesse gilt also dem Abschnitt "27. Flash Memory" im Datenblatt. Hier steht

The flash memory can be programmed in the following three modes: CPU rewrite mode, standard serial I/O mode, and parallel I/O mode.

Das beduetet das im "CPU Rewrite Mode" eine von der CPU ausgeführte Software für die Flash-Programmierung sorgt. Das dürfte beim normalen Update über OBD/CAN der Fall sein. Da wird dann ja ein Stück Software ins RAM des BCM geladen und ausgeführt, welches dann das Update durchführt. Sowas geht auch, mich interessiert aber erstmal die Hardware-Nahe Variante. Und hier gibt es dann den "Serial IO" und "Parallel IO" Modus.

Der Serial IO ist der mit dem UART und der spannende für mich! Diesen kann man in zwei Modus betreiben:

Mode 1: Synchronous serial I/O

Mode 2: UART serial I/O

Ich würde Mode 2 wählen, das entspricht einer normalen seriellen Schnittstelle mit variabler Baud-Zahl, ohne zusätzliches Taktsignal wie beim Mode 1 notwendig.

Die Programmier-Operation erfolgt auf Byte-Level, also kann auch ein einzelnes Byte programmiert werden.

Die Lösch-Operationen erfolgen auf Block-Basis, wie groß der auch immer ist, aber zumindest muss man nicht alle Blöcke löschen.

Beides ermöglich interessante Angriffsvektoren, z.B. durch einschleusen eines Trojaners in unbenutzte Teile des Flash-Speichers.

Die Bereiche Program-Flash (768k) und Data-Flash (8k) können getrennt voneinander bearbeitet werden. Ausführbarer Code muss sich jedoch im Program-Flash befinden. Das Program-Flash belegt die Blocks 0-13, das Data-Flash die Blocks A und B. Jeder Block kann auch individuell geschützt sein (Lock-Bits). Der Block 0-13 belegt die Speicheradressen 0xFFFF 4000 bis 0xFFFF FFFF. Daneben gibt es auch eine sog. "ID Code Protection", so eine Art "Passwort" bestehend aus 7 Bytes. Dazu aber irgendwann später mehr...

Die gesamte Lösch und Programmieroperation erfolgt per Software. Es gibt insgesamt 9 Kommandos die der Bootloader über die UART verarbeiten kann. Diese sind ab Abschnitt "27.4 Standard Serial I/O Mode" dokumentiert. Dort kommen wir auch zu den zu verwendenden Signalen/Pins des Chips.

Freundlicherweise gibt es im Datenblatt auch gleich ein Anschlußschema für den "Programmer":

Es müssen also einige Pins auf definierte Pegel gezogen werden. Über das Signal "CNVSS" wird zwischen Bootloader- und Programm-Ausführung umgeschaltet. Legt man das Signal auf HIGH (Vcc) wird der Bootloader nach einem /RESET (kurz auf LOW) ausgeführt, ansonsten startet das Programm. Die Kommunikation geschieht dann über die Port-Pins "P6_6" für RXD und "P6_7" für TXD. Über den Pin "P6_4" (BUSY) kann man erkennen wann der Chip einen Befehl fertig ausgeführt hat. Das wäre bei Flash-Lösch-Operationen hilfreich die länger brauchen als Einzelbefehle.

Hier mal auf das Gehäuse der MCU bezogen die Pins die benötigt werden:

• VCC (Betriebsspannung/Signalspannung) => Pin 91
• VSS (GND) => Pin 23
• CNVSS => Pin 16
• /RESET => Pin 19
• RXD (P6_6) => Pin 40
• TXD (P6_7) => Pin 38
• SCLK (P6_5) => Pin 42
• BUSY (P6_4) => Pin 43
• /EPM (P5_5) => Pin 54
• /CE (P5_0) => Pin 65

Man kann nun eine Betriebsspannung von außen anlegen oder aber man legt Spannung an das BCM. Legt man selbst Spannung an, versorg man damit möglicherweise unweigerlich das ganze Board und ob das die externe Quelle leisten kann müsste vorab geprüft werden. Auch weiss ich noch nicht welche Betriebsspannung überhaupt verwendet wird. Laut Datenblatt kann die MCU 3.0 bis 5.5 Volt. Also messe ich lieber erstmal nach.

Dazu versorge ich das BCM über den Hauptstecker an den Pins mit +12V:

Masse (GND) hole ich über Pin 1 vom "blauen" Stecker:

Ohne irgendwelche Beschaltungen meinerseits hört man beim anlegen der Betriebsspannung deutlich Relais klicken. Danach pendelt sich die Stromaufnahme auf ca. 245 mA ein. An der MCU messe ich eine Betriebsspannung von 5.0 Volt. Damit ist dann auch der benötigte Pegel der o.g. Signale klar.

Als nächstes geht es auf die Suche nach geeigneten Anschlüssen für die Signale. Bei Programmieradaptern vermute ich zunächst immer irgendwo auf dem Board einen nicht bestückten "Debug-Header". Meist richten sich die Ingenieure nach den Vorgaben der Chip-Hersteller wie der auszusehen hat und zu beschalten ist. Auf dem Board fällt mein Blick sofort auf diese Durchkontaktierungen auf der Platinenrückseite, unterhalb der Dachhimmel-Anschlussbuchse C5:

Diese habe ich dann mal auf "Gut Glück" in Richtung der MCU durchgemessen und siehe da, alle benötigten Signale liegen dort auf!

Um besser damit arbeiten zu können habe ich eine zweireihige Stiftleiste in die Kontakte gelötet

Das ist nicht ganz trivial da die gesamte Platine in Lack getaucht/besprüht wurde, was die Lötaufnahme erheblich erschwert. Man sollte die Kontakte vorher unbedingt mechanisch vom Lack befreien, sonst hat man keine schlüssige Verbindung.

Ich komme da auf folgende Belegung:

Bevor ich nun anfange mit der MCU in Kontakt zu treten, führe ich die Signale über Dupont-Wires auf ein Steckbrett und verschalte sie wie im Datenblatt angegeben. Dort habe ich dann auch einen Reset-Taster aufgesteckt, sowie einen Umschalter für den Betriebsmodus "Programmieren" und "Ausführen". Der Umschalter führt das CNVSS Signal dann jeweils nach GND oder +5V.

Der erste Test zeigt das in der Stellung "Programmieren" die Stromaufnahme deutlich geringer ist, nur ca. 50 mA. Während man den Reset drückt sogar nur 34 mA. Das zeigt: Ich bin auch dem richtigen Weg!

Merkwürdig ist allerdings das im Programmier-Modus die Stromaufnahme periodisch schwankt, zwischen 50 mA und 54 mA. Das macht mich etwas stutzig und aus Erfahrung habe ich mir das RESET-Signal mal mit dem DSO angeschaut um zu sehen ob es stabil ist und nur meinem "Taster" folgt. Wie schon befürchtet sieht man ein periodisch erzeugtes RESET, alle 65 ms:

Das bedeutet für mich das noch etwas anderes einen RESET ausführt, vermutlich wie üblich, über einen externen Baustein. Den gilt es erstmal zu finden, sonst komme ich mit der Kommunikation zum Bootloader nicht weiter. In anderen Modulen wird hier ein spezieller Watchdog-IC im SOT-326 Gehäuse verwendet. Die gibt es mit festen Timeout-Werten.

So, auch dieses Rätsel konnte ich lösen. Zunächst habe ich mich gewundert warum auf der Platine nicht die üblichen Spannungsregler-Aufbauten zu finden sind. Watchdog-Schaltkreise befinden sich häufig in der Nähe da diese manchmal auch eine Brown-Out-Detetion (Unterspannungserkennung) durchführen und dann den Spannungsregler abschalten.

Leider sind ja alle Chips ordentlich mit Harz vollgekleckst sodass man ihre Bezeichnungen erstmal nicht erkennen kann. Kratzt man diesen Harz vorsichtig mit dem Cuttermesser oder Flachschraubendreher runter, werden die Markings mehr oder weniger gut lesbar (wer eine bessere Methode kennt bitte melden! Außer Aceton, gelle, also abbeizen wollte ich die Chips nicht, das löst ggf. das Epoxy auf/an).

Durch nachmessen der RESET-Leitung auf ein paar Bausteine bin ich dann auf dieses IC gestoßen:

Der Infineon TLE7263E ist ein sogenannter "SBC", ein "System Basis Chip". Er enthält u.a. einen CAN- und LIN-Transceiver, Schaltausgang, div. Eingänge, Überspannungs/Temperatur-Überwachungen, einen Spannungsregler (LDO) und - einen Window-Watchdog! Er ist also quasi die Platinen-STASI. Er kümmert sich auch um die Sleep-Modi und Wakeup-Erkennung. Also rundum ein toller Chip.

Für die Watchdog-Funktion gibt er auf dem RO-Pin 26 ein /RESET-Signal aus. Dieser Pin ist direkt mit dem R32C /RESET und dem Header-Pin verbunden. Im Datenblatt unter "4.12 Window Watchdog, Reset" findet man auch die Erklärung für das Reset-Timing:

After the above described delayed reset (LOW to HIGH transition of RO) the window watchdog circuit is started by opening a long open window of typ. 64 ms. The long open window allows the microcontroller to run its initialization sequences and then to trigger the watchdog via the SPI.

D.H. die 64 ms reichen in der Regel dicke aus damit ein durch den SBC versorgter Mikrocontroller startet und den Watchdog mittels der SPI-Schnittstelle umprogrammiert, bzw. periodisch "entschärft".

Nun, da ich weiss warum und wer den RESET auslöst gilt die Frage zu klären wie man das verhindern kann?

Die Antwort hierzu findet sich ebenfalls im Datenblatt des ICs im Abschnitt "4.19 Flash Program Mode":

For flash programming it is useful to disable the window watchdog function. This can be done by applying a voltage of VINT > 7.0 V at pin INT. This is useful e.g. if the flashmemory of the micro has to be programmed and therefore a regular watchdog triggering is not possible.

Den "VINT" (Pin 17) habe ich auf der Unterseite der Platine bis zu diesem Test-PAD verfolgt und dort nach freilegen der Pads eine Leitung angelötet:

Diese habe ich dann über einen 1kOhm Widerstand an +12V verbunden (VINT muss nur größer 7.0V sein, 12V reichen also) und siehe da, schon haben wir eine schöne "Flatline" auf dem /RESET Signal!

Nun wollte ich endlich mit dem Teil quatschen. Also habe ich meinen FTDI-Adapter rausgekramt. Ich nutze hier ein solches Board für wenige Euro vom Chinesen:

das gibt es auch als "Kabel":

Für ein paar Euro mehr bekommt man es mit einem echten FTDI-Chip drauf (was schon eher selten ist, das meiste sind Clones, also meist umgelabelte PICs und die sind nicht immer brauchbar).

Also GND, RESET, TXD und RXD mit dem Board verbunden und HTERM gestartet - ABER was nun? Über den "DTR" Button kann ich den Reset auslösen.

Leider steht im Datenblatt vom R32C aber nichts darüber wie ich nun mit dem Bootloader spreche, also welche Kommandos der im UART im Mode 2 erwartet und verarbeitet. Also ist erstmal wieder recherchieren angesagt...

Fündig wurde ich in diesem Papier eines anderen Tüftlers: flash-guide.pdf

Darin beschreibt er die Kommunikation mit einer M32C MCU, nicht ganz dasselbe, aber der Bootloader ist wohl vergleichbar.

Er schreibt das man zunächst 16 0x00 Bytes im Abstand von mind. 20 ms senden muss, damit sich der Bootloader auf die Serial-Geschwindigkeit einstellt. Für den Start wird 9.600 Baud mit 8 Daten-Bits, Kein Parity, 1 Stop-Bit vorgegeben (9600 8N1). In dieser Phase gibt der Bootloader noch keine Antwort zurück.

Nun könnte man die Baudrate ändern oder ein anderes Kommando senden. Eines wäre 0xFB welches den Bootloader seine Version senden lassen sollte.

Leider erhalte ich nichts im Hterm zurück. Also DSO ans Sendesignal und festgestellt das der Signalpegel vom FDTI bei Verbindung mit dem Board nicht tief genug runter geht:

Klemme ich das TXD vom Board ab, geht der Low bis auf GND runter. Irgendwas blockiert hier also die Übertragung.

Also ich den Watchdog noch nicht gefunden hatte, sah das zum Teil so aus:

Während der RESET-Phase sind die Ausgänge der MCU hochohmig und so konnte der FTDI das TXD ganz auf GND ziehen. Sobald das RESET wieder HIGH war und die MCU startete, zog sie den Pegel wieder fast bis auf VCC (+5V) hoch. Die beiden DSO-Snaps zeigen anschaulich wann der RESET anlag und wann nicht mehr.

Wäre ja auch zu einfach gewesen, nicht wahr?!

Ok, auch dieses Problem konnte ich nun lösen. Nach langem suchen bin ich darauf gestoßen das der vermeintlich am Debug-Header vorhandene "RXD1" der MCU eben leider nicht dort anliegt. Da bin ich beim durchmessen wohl verrutscht!

Aus mir nicht erklärbarem Grund liegt dieses wichtige Signal garnicht am Header an, ich habe es auf einem Test-Pad unterhalb des blauen Steckers gefunden. Hier kann man ein Kabel anlöten.

Somit hier das geänderte Anschlußschema:

Nun kann ich auch endlich die gewünschte Kommunikation mit dem Bootloader durchführen und das DSO-Signal sieht nun sauber aus:

Also sende ich zunächst wieder die 16 Sync-Bytes (00) und anschließend "FB", was mir die Bootloader-Version zurück gibt:

Nun das die grundsätzliche Kommunikation da ist geht es ans Eingemachte, ich versuche den UNLOCK durchzuführen.

Laut Dokumentation ist hierfür das Kommando "F5" zuständig. Dieses Erhält 3 zusätzliche Parameter und hat diesen Aufbau:

F5 <ADDR1> <ADDR2> <ADDR3> <PASSWORD-LEN> <PASSWORD BYTES...>

Die ADDR-Bytes sind dabei die letzten 3 Bytes der Flash-Adresse. In unserem Fall steht das password im Flash an 0xFFFF FFFE8 und ist 7 Bytes lang. Somit ergibt sich:

F5 E8 FF FF 07 <PASSWORD BYTES...>

Nachdem man ein UNLOCK-Passwort gesendet hat, kann man den Erfolg aus dem Status auslesen, welchen man mit dem Kommando "70" erhält. Der Bootloader sendet daraufhin 2 Bytes zurück. Der interessante Teil über den UNLOCK-Status findet sich im zweiten Byte and den unteren Bit-Positionen (LL):

xxxx LLxx

LL = "00" = "No password send yet"

LL = "01" = "Invalid password send"

LL = "11" = "Correct password send"

Mein erster Versuch wären die Default-Passwörter, das sind "alles 0x00" oder "alles 0xFF". Also

F5 E8 FF FF 07 00 00 00 00 00 00 00

Ergibt bei Statusabfrage:

80 04

04 in Binär ist 0000 0100 über die o.g. Maske bedeutet das "Invalid password send". Ok, dann das andere

F5 E8 FF FF 07 FF FF FF FF FF FF FF

und ich bekomme:

80 0C

0C in Binär ist 0000 1100 = "Correct password send" - HURRA!

Nun kann ich also versuchen die internen Flash-Speicher auszulesen. Da ich kein passendes Tool dafür zur Hand habe, muss ich mir halt eins programmieren. Dafür werde ich etwas Zeit brauchen. Bis dahin viel Spaß beim schmökern und experimentieren!

P.S.: Es gibt hier und da Berichte im Internet das die MCU eine Art "Selbstzerstörung" hätte, wenn man zu oft das falsche Password versucht. Das ist Quatsch. Vielmehr ist es so das ein Brute-Force, also das einfache durchprobieren aller möglichen Kombinationen mit 7 Bytes Passwordlänge Jahrzehnte in Anspruch nehmen würde.

Nun geht es ans auslesen der insgesamt 3 Flash-Speicher, dem User-Flash, Data-Flash und EEPROM-Flash (E2-Flash). Die Adressen dieser Speicherbereiche kann man dem Datenblatt entnehmen (Memory Map):

Der User-Flash startet bei 0xFFF4 0000 und geht bis 0xFFFF FFFF (die letzten DWords enthalten die sog. Vector-Tabelle, das wird später mal beim disassemblieren wichtig sein)

Der Data-Flash startet bei 0x0006 0000 und geht bis 0x0006 2000. Laut Datenblatt ist er unterteilt in zwei Bereiche, Block A und Block B.

Das Bootloader-Kommando zum auslesen des Flash lautet "FF". Dieses liest immer 256 Bytes von der nachfolgend genannten Speicheradresse und gibt diese zurück. Die Speicheradresse muss man beim R32C etwas kompliziert angeben, weil das Bootloader-Protokoll ursprünglich für 20-Bit CPUs entwickelt wurde. Aufgrund der 256 Byte Blockgröße (=0x100) werden immer nur die oberen Bytes der Adresse benötigt da man ja nur in den Block-Grenzen lesen kann, nicht mittendrin. Dazu folgen dem Kommando 2 Adressbytes im Little-Endian Format (niederwertiges Byte zuerst).

FF <ADDR2> <ADDR1>

Da der R32C aber eine 32-Bit CPU ist, wird noch ein weiteres Adressbyte benötigt. Hier wurde kurzerhand das Protokoll erweitert und man sendet ein "48" mit dem zusätzlichen ersten, höchstwertigen, Adressbyte vorn weg:

48 <ADDR1> FF <ADDR3> <ADDR2>

Um die ersten Bytes an der Flash-Start-Adresse 0xFFF4 0000 zu erhalten wäre das nacheinander geschrieben also:

FF => ADDR1

F4 => ADDR2

00 => ADDR3

00 => Wird nicht benötigt.

Somit ergibt sich dieses Kommando:

48 FF FF 00 F4

Ok, das hat geklappt, aber bevor ich jetzt anfange einen eigenen Programmer zu schreiben, bediene ich mich lieber verfügbaren Tools. Der Chip-Hersteller Renesas stell hierfür das Flash Development Tool (kurz FDT) bereit. Hier der Download-Link zur Version 4.09

https://www.renesas.com/us/en/document…se-03?r=1169901

Für einen Download wird ein Login verlangt, man muss sich also vorher registrieren. Ich habe das Tool mal angefügt.

Nach der Installation startet man es und legt einen neuen Workspace an:

Nun wählt man den richtigen MCU-Typ, hier am besten die Langbezeichnung eingeben "R5F64524" dann erscheint direkt das Richtige. Den ersten Eintrag (ohne _ECC) anwählen und bestätigen:

Danach wählt man den Adapter-Typ. Bei eingestecktem FDTI-Adapter/Kabel wird dieser direkt vorausgewählt. Ggf. muss man den richtigen COM-Port aber einstellen:

Dann noch die "Protection" auf "None" stellen:

und das Projekt ist angelegt:

Als erstes stellen wir dann das Passwort ein.

Hierzu den "Zauberstab" in der Menüleiste anklicken um die Zusatzfunktionen zu aktivieren.

Dort dann den Reiter "Communications" wählen und einen Doppelklick auf "Auto Send ID" machen, das Passwort (alles "FF") eingeben und bestätigen:

Jetzt das BCM mit Betriebsspannung versorgen, in den UART-Mode2 bringen und einmal kurz mit einem RESET versorgen um den Bootloader zu starten.

Dann den "Connect" Button drücken:

Wenn alles klappt sieht man im Meldungsfenster rechts unten die Verbindung und es erscheint noch ein Dialog ob er den Chip komplett entsperren soll. Den belassen wir erstmal auf "Nein" weil wir ja zunächst nur auslesen wollen:

Durch Klick auf den "Upload" Button (ja, der heißt leider so, finde ich auch komisch) starten wir den Lesevorgang:

Es erscheint ein Dialog zur Auswahl des Flash-Bereiches. Da wählen wir aber den Reiter "Tree":

und klicken "Select All"

und anschließend "Upload":

Den Fortschritt kann man im Fenster kontrollieren, jetzt heißt es abwarten:

Nachdem der Download beendet wurde kann man die einzelnen Teile als Datei abspeichern. Hier wählen wir das "MOT" Format, damit neben den Daten auch gleich deren Speicherbereichsadressen mit abgelegt werden, was einen späteren Flash im anderen BCM erleichtert:

<FOTO>

Am Ende haben wir nun das komplette Flash vom BCM auf der Festplatte -> Das erste Etappenziel ist erreicht!

fdtv409r03-doc-e.zip

"Auf zur Bergspitze!" - dem Clone meines BCM.

Ich baue also mein BCM (ohne RDKS-Elektronik) aus und lade die darauf befindliche Firmware und Daten wie oben genannt herunter. Anschließend programmiere ich den gesamten Inhalt auf das neue BCM (mit RDKS-Elektronik). Sollte dabei was schief gehen, habe ich das neue BCM geschrottet, aber mein altes ist noch unberührt und kann wieder ins Auto gebaut werden.

Die Idee dahinter ist:

a) Der Flash-Dump enthält neben der Firmware und der CCC vor allem auch die PATS-II Hashes/Codes (oft auch als Schlüssel-Codes bezeichnet) und somit sollten die im neuen BCM dann direkt funktionieren.

b) Die Firmware ist grundsätzlich für alle BCMs gleich, egal welche HW-Generation innerhalb einer Baureihe (vFL, FL), sodass die Firmware auch "Cross-Over" getauscht werden kann.

Das werde ich zum nächstmöglichen Zeitpunkt ausprobieren und berichten!

Tja, wie es immer so ist im Leben (oder in meinem Leben): nichts klappt auf Anhieb einfach so wie man es plant

Ich habe gestern mein BCM ausgebaut und ausgelesen. Das klappte hervorragend, so wie auch beim neuen BCM. Anschließend habe ich das neue BCM löschen und programmieren wollen. Aber bereits beim löschen des Flash gab es Probleme (Timeouts) die ich aber mit Hartnäckigkeit und langem warten am Ende noch in den Griff bekommen habe. Will sagen, irgendwann hat es dann geklappt. Das gilt es aber noch zu untersuchen und zu stabilisieren.

Beim Programmieren ging es im User Flash und Data Flash ohne Probleme, aber das E2 Data Flash will zum verrecken nicht und genau da stehen wohl die PATS Codes drin. Der E2 Flash ist ein im Flash-Speicher simuliertes EEPROM. Die MCU stellt dafür spezielle Register bereit die es der Software erlauben zur Laufzeit, unterbrechungsfrei, Daten auf Byte-Level im EEPROM zu speichern. Es kann also ein einzelnes Byte löschen und neu programmieren. Da dürfte also der gesamte Persistenz-Layer vom BCM drin stecken, sowas wie DTCs, Anlernwerte (z.B. die RDKS-Sensordaten) etc.

Folgende Aufteilung ist inzwischen klar:

• User Flash => Firmware (so wie sie im Update-VBF steht)
• Data Flash =>
  • An Position 0x0006 0000 liegen noch unbekannte 6 Bytes
  • An Position 0x0006 1000 liegt mit 0x200 Bytes die vollständige CCC
• E2 Data Flash => DTCs, RDKS-Sensor-IDs, etc.
  • An Position 0x0006 2A20 liegen die RDKS-Sensor-IDs (Little-Endian Format, also byteweise "rückwärts" lesen)
    

Entweder mache ich noch grundlegend was falsch oder es gibt noch einen Schutzmechanismus speziell für das E2 Flash, welchen ich noch nicht entdeckt habe. Und so musste ich erstmal mein altes BCM wieder einbauen.

Es bleibt also spannend...

Es verdichtet sich der Verdacht das ich einfach das Glück habe ein BCM mit defektem Flash-Speicher in der MCU erwischt zu haben. Womöglich war das auch der Grund für den Verkauf und wurde verschwiegen... Ein bekannter Elektronik-Tüftler hat dasselbe mit einem gebrauchten BCM gemacht und kann die o.g. Programmierung völlig störungsfrei durchführen. Na toll... da ich aber mein BCM im Auto nicht riskieren kann muss ich mir jetzt wohl oder übel noch eins zulegen.

Ich habe den Fehler gefunden: Mein Laptop mit i7 Prozessor, mit dem ich die Programmierungen durchführe ist einfach zu schnell! Das Bootloader-Protokoll stammt aus einer Zeit wo die Rechenleistung der PCs noch überschaubar war. Nach langer Suche bin ich auf einen Flash-Programmer für einen anderen Renesas Chip auf Github gestoßen wo jemand genau dieses Problem beschrieben hatte. Das FDT unterstützt zwar die alten Prozessoren, es wurden aber keine Zwangstimings dort integriert und so kann es wohl passieren das die Software Befehle zu früh absendet und der Bootloader diese nicht verarbeitet. Das waren dann die komischen Effekte die ich hatte. Mal klappte es, mal nur ein bisschen, mal garnicht. In besagtem Github-Projekt hat sich der Programmierer deshalb einen eigenen Flash-Programmer geschrieben welcher mit Zwangspausen arbeitet um das Timing der alten PCs nachzuahmen, bzw. sich experimentell herangetastet was der Chip noch verarbeiten kann.

Aus dieser Information heraus habe ich dann das FDT auf dem ältesten Laptop installiert den ich rumliegen hatte und der eigentlich zum verschrotten geplant war. Und siehe da, gleich beim ersten Mal konnte ich wie oben angegeben das neue BCM mit dem Flash meines alten beschreiben. Völlig problemlos!

Danach habe ich das geclonte BCM natürlich gleich ins Auto gepackt und

Es klappt! Keine Wegfahrsperre, alles funktioniert, der Clone ist vollständig und erfolgreich!

Damit haben wir dann mal wieder ein großes Problem gelöst, Umbau eines BCM ganz ohne Schlüsselprogrammierung.

Auch ein Punkt zur Beachtung ist der das nach einem Clone natürlich die BCM Daten der Firmware nicht mit denen auf dem Gerät übereinstimmen. Die Seriennummer und die HW Version sind die alteb. Auch das könnte mit einem Patch behebbar sein. Es ist ohnehin noch zu kläreb ob es evtl. nicht sogar ausreichend ist nur den E2 Data Flash zu clonen in dem mutmaßlich die PATS Codes drin stehen?