CCC programmer

Beim Keyless-System geht der ZV-Schalter vorn links ans Keyless-Modul (C5 Pin 10). Der schaltet dieses Signal einfach nur auf GND, oder halt nicht (interner Pullup im Modul).
Das Keyless-Modul steuert auch direkt die ZV-Motoren an. Ebenso sind die Funkempfänger für den Funkschlüssel dort mit dran. Zwar wird es über den MS-CAN bestimmt die Vorgänge melden, aber sicher nicht empfangen und ausführen. Wenn Du Keyless-Go im Fahrzeug hast, könntest Du einfach einen weiteren Schalter parallel dazu installieren. Pin 2 (Braun/Grüne Leitung) vom Schalter auf deinen und dann auf GND. Das Signal lässt sich sicher besser am Modul "anzapfen" (Pin 10, Leitungsfarbe Braun) und dann zur Beifahrertür legen.

Bei Systemen mit Schlüssel ist der ZV-Schalter mit einer LIN-Schnittstelle ausgestattet und geht auf den LIN-Bus zwischen Fahrertürmodul und Fonttürmodul fahrerseite. Mit LIN hab ich noch nichts weiter gemacht, aber vom Prinzip her ist das auch ein Bus. Du könntest also wie bei der Keyless-Lösung einfach den zweiten ZV-LIN-Schalter mit auf den LIN-Bus des ersten klemmen. Das sollte funktionieren.

Zitat von BBG-AE185

Klappt aber nur beim FL. Die vFL haben die zusätzliche Glühkerze nicht.

Soweit ich es bislang ermitteln konnte gibt es nicht sowas wie ein Bit-Signal im CAN welches sagt "Regeneration läuft". Man muss es wohl aus "Nebeneffekten" selbst ermitteln. Einer wäre das genannte Schaltsignal fürs Relais der Glühkerze. Ein anderer die DPF-Temperatur (geht dann so bis 700°C) oder auch die Kilometerzähler der Regeneration.

Zitat von BBG-AE185

Die DTCs kommen ja weil das BCM während der Programmierung nicht ansprechbar ist. So hast Du in allen Modulen die DTCs "Verbindung zum BCM verloren" die in den Modulen gelöscht werden sollten.

Klingt zwar logisch, aber das hatte ich nach dem programmieren noch nie machen müssen.
Sobald das BCM in den Programmiermodus wechselt hört es auf auf den CAN-Bussen seine IDs zu senden. Es gibt nur noch die Kommunikation mit dem Diagnosegerät. Dadurch geht auch die permanent gesendete ID 048 (60ms Takt) ab in welcher der Betriebszustand des Fahrzeugs gemeldet wird (Zündung an/aus). Dies könnte die Module zum sofortigen "einschlafen" bringen, wodurch sie nichts von einem Kommunikationsverlust mitbekommen. Vielleicht wird da auch kurz vor dem Programmieren sowas wie ein "CAN-Narkosemittel" injeziert Ich werde mir das bei meiner "Labor-Ratte" mal genauer ansehen.

Ich habe mir den Programmiervorgang der CCC ins BCM auf dem HS-CAN mal genauer angesehen und folgendes herausgefunden:

Jedes Modul im Mondeo hat auf dem CAN-Bus eine eigene Node-ID unter dem es sich angesprochen fühlt (sieht man z.B. im ELMConfig wenn man ein Modul anklickt). Sonst ist der CAN-Bus ja nachrichtenorientiert, aber in diesem Fall ist die ID Geräteorientiert. Dies wird zum auslesen/löschen von DTCs verwendet, aber auch zum programmieren der Module. Früher, als es noch keine CCC gab musste die Konfiguration in die jeweiligen Module geschrieben werden. Der Mondeo MK4 muss diese nur ins BCM (und IPC) schreiben.

Das macht er, indem er an das BCM-Modul, welches die Node-ID 0x726 hat, ein kleines Programm (Bootloader) sendet welches dieses dann ausführt. Dieses Programm empfängt dann vermutlich die CCC und schreibt sie ins Steuergerät. Das Format dieses Programms ist VBF (Volvo-Binary-File). In diesem steckt am Ende der binäre Bootloader. Sobald ich rausgefunden habe was der BCM für eine CPU ist werde ich mir mit einem Disassembler daraus mal den Assembler-Code bauen und lesen.

Sobald dieser Bootloader die Kontrolle übers BCM hat, sendet dieses keine CAN-IDs mehr aus, der Bus ist quasi "Totenstill". Das mag auch der Grund für div. Störmeldungen in den Modulen und dem IPC sein. In dieser Zeit wird die CCC übertragen. Ist der Vorgang abgeschlossen startet das BCM neu. Dieser Neustart dauert, im Gegensatz zu PCs wirklich nur ein paar Millisekunden

Als CAN-Protokoll schaut das dann in etwa so aus:

18,502 726      8 02 10 02 00 00 00 00 00
18,502 72E      8 06 50 02 00 19 01 F4 00
19,267 726      8 03 22 D1 00 00 00 00 00
19,268 72E      8 04 62 D1 00 02 00 00 00
19,627 726      8 02 27 01 00 00 00 00 00
19,627 72E      8 05 67 01 E6 A8 C5 00 00
19,891 726      8 05 27 02 B4 72 FD 00 00
19,892 72E      8 02 67 02 00 00 00 00 00
20,157 726      8 10 0B 34 00 44 00 00 04
20,158 72E      8 30 00 00 00 00 00 00 00
20,174 726      8 21 10 00 00 26 CA 00 00
20,174 72E      8 04 74 20 01 02 00 00 00
20,440 726      8 11 02 36 01 4C C8 45 C8
20,441 72E      8 30 00 00 00 00 00 00 00
20,456 726      8 21 3F EA AC FF BF 00 00
20,471 726      8 22 4D E8 3F EA 8C FF BF
20,486 726      8 23 00 00 4C E8 3F EA 2C
20,502 726      8 24 C7 2B 00 00 12 FA 01
20,518 726      8 25 B2 6C CB 00 00 00 B2
20,533 726      8 26 AC 00 B4 00 00 D6 08
...
01,371 72E      8 02 76 02 00 00 00 00 00
01,636 726      8 01 37 00 00 00 00 00 00
01,636 72E      8 03 7F 37 78 00 00 00 00
01,638 72E      8 03 77 34 C0 00 00 00 00
01,903 7DF      8 02 11 81 00 00 00 00 00

Ich verstehe es so:

18,502 726 8 02 10 02 00 00 00 00 00
Die Diagnosesoftware (ELMConfig) sendet an das BCM einen OBD-PID. Diese enthalten in Byte 1 die Anzahl der folgenden Bytes. In Byte 2 den PID-Modus und Byte 3 den PID-Code. Der PID-Modus 0x10 ist nicht genorm, das muss was Ford-Spezifisches sein. Genormte PID-Modes gehen nur bis 0x0A. Damit ist mir auch der PID-Code unklar.

18,502 72E 8 06 50 02 00 19 01 F4 00
Das BCM sendet an die Diagnosesoftware (diese hat immer die Node-ID 0x72E) eine Antwort mit 6 Bytes. 0x50 ist dabei die positive Antwort auf die Anfrage nach PID-Mode 0x10 (positive Antworten enthalten den angefragten Mode-Code + 0x40). Es folgen noch 5 Bytes deren Inhalt ich derzeit nicht entschlüsseln kann.

Es folgen weitere Anfrage/Antwort-Pakete dieser Art:

19,267 726 8 03 22 D1 00 00 00 00 00
19,268 72E 8 04 62 D1 00 02 00 00 00

19,627 726 8 02 27 01 00 00 00 00 00
19,627 72E 8 05 67 01 E6 A8 C5 00 00

19,891 726 8 05 27 02 B4 72 FD 00 00
19,892 72E 8 02 67 02 00 00 00 00 00

20,157 726 8 10 0B 34 00 44 00 00 04
20,158 72E 8 30 00 00 00 00 00 00 00

20,174 726 8 21 10 00 00 26 CA 00 00
20,174 72E 8 04 74 20 01 02 00 00 00

Der nachfolgende ist wieder interessant, da hier die Diagnosesoftware nun mehr als ein Paket für das BCM sendet. Das ist an dem Zähler, beginnend mit 0x21 im ersten Datenbyte der Nachrichten zu erkennen. Ab hier wird dann vermutlich der Bootloader übertragen:

20,440 726 8 11 02 36 01 4C C8 45 C8
20,441 72E 8 30 00 00 00 00 00 00 00
20,456 726 8 21 3F EA AC FF BF 00 00
20,471 726 8 22 4D E8 3F EA 8C FF BF
20,486 726 8 23 00 00 4C E8 3F EA 2C
20,502 726 8 24 C7 2B 00 00 12 FA 01
20,518 726 8 25 B2 6C CB 00 00 00 B2
20,533 726 8 26 AC 00 B4 00 00 D6 08
...
01,371 72E 8 02 76 02 00 00 00 00 00

Nach erfolgter Programmierung sendet ELMConfig noch etwas, was das BCM nicht mag (erkennbar am Reply-Code 0x7F, was eine nagative Rückmeldung bedeutet):

01,636 726      8 01 37 00 00 00 00 00 00
01,636 72E      8 03 7F 37 78 00 00 00 00

01,638 72E 8 03 77 34 C0 00 00 00 00

Die letzte Nachricht ist wieder intressant, denn die Node-ID 0x7DF ist ein Broadcast. D.H. diese Info geht an ALLE Module auf dem Bus. Ich glaube das ist sowas wie eine RESET-Meldung vom ELMConfig, damit alle die Änderungen in der CCC übernehmen können:

01,903 7DF      8 02 11 81 00 00 00 00 00

So, wieder etwas schlauer

Im ersten Schritt einer CCC-Programmierung ermittelt ELM den Typ des BCM um den richtigen Bootloader auszuwählen (sofern beim BCM-Modell "Auto" gewählt ist).
Dies sieht als CAN-Trace so aus:

27,584 726      8 02 3E 80 00 00 00 00 00     -> BCM: Mode 0x3E (???)
27,847 726      8 03 22 F1 13 00 00 00 00     -> BCM: Diagnosedaten nach PID-Adresse 0xF1 (=Externe Diagnosetester)
27,863 72E      8 10 1B 62 F1 13 41 47 39    -> ELM: Antwort über mehrere Frames folgt. Mode 0x22 bestätigt. Anfragedaten gespiegelt. Beginn der ersten Antwort-Daten (3 Bytes)
27,863 726      8 30 00 00 00 00 00 00 00 -> BCM: Mehrfach-Frames akzeptiert.
27,873 72E      8 21 54 2D 31 34 41 30 37  -> ELM: 2. Frame
27,883 72E      8 22 33 2D 44 41 00 00 00 -> ELM: 3. Frame
27,893 72E      8 23 00 00 00 00 00 00 00 -> ELM: 4. und letztes Frame

Gut zu beobachten hier das CAN-Bus Konzept der "Multi-Frame" Nachrichten. Dabei werden Daten welche nicht in eine einzelne CAN-Nachricht passen (also mehr als 8 Byte haben) in mehrere aufeinanderfolgende Nachrichten aufgeteilt. Und das geht so:

• Bei einer Antwort die vollständig in eine CAN-Nachricht passt, wäre das erste Byte einer OBD-Antwort die Anzahl der nun folgenden Bytes. Da in eine CAN-Nachricht nur max. 8 Byte passen, dürfte hier also höchstens der Wert 0x07 stehen.
• Der Sender der langen Nachricht (hier das BCM) signalisiert durch ein 0x10 im ersten Byte jedoch das die Antwort länger und auf mehrere Nachrichten aufgeteilt werden muss. Die Menge der Daten die er beabsichtigt zu senden folgt im nächsten Byte, nämlich 0x1B (27 dezimal) Bytes. Danach folgt die positive Bestätigung des Mode 0x22 mit dem Wert 0x62. Bei positiver Rückmeldung wird auf den angefragten Mode-Wert einfach 0x40 addiert. Bei negativer Antwort stünde hier ein 0x7F drin. Abschließend folgen die restlichen Bytes der Anfrage: 0xF1, 0x13. Dann erst beginnen die eigentlichen Antwortdaten. Bis zum Ende dieses Frames sind das: 0x41, 0x47, 0x39
• Der Empfänger der Nachricht (ELMConfig) erkennt die Multi-Frame Sequenz und signalisiert seine Empfangsbereitschaft indem er ein einzelnes 0x30 sendet (die Restlichen Bytes der Nachricht werden einfach mit 0x00 "aufgefüllt").
• Sobald der Sender (BCM) das erkannt hat, sendet er nacheinander, ohne weiteres Handshakeing die restlichen Frames die es braucht bis alle Daten übermittelt sind. Dabei enthält jedes Paket im ersten Byte einen Sequenzzähler, beginnend mit 0x21. Es werden also nur je 7 Nutzbytes pro Nachricht übermittelt.
• Der Empfänger (ELMConfig) hat im Voraus berechnet wieviele Sequenzen kommen, indem er die Länge von 27 Bytes durch 7 geteilt und aufgerundet hat. Das Ergebnis sind 4 Frames. Eines hat er zu diesem Zeitpunkt bereits empfangen, fehlen also noch 3. Damit ist klar, das der letzte Frame empfangen wurde, wenn der Sequenzzähler den Wert 0x23 erreicht hat.

Die gesamte, zusammengesetzte Nachricht lautet dann so:
1B 62 F1 13 41 47 39 54 2D 31 34 41 30 37 33 2D 44 41 00 00 00 00 00 00 00 00 00 00

Ziehen wir davon den Protokoll-Header ab, bleiben folgende Nutzdaten:
41 47 39 54 2D 31 34 41 30 37 33 2D 44 41 00 00 00 00 00 00 00 00 00 00

Die hinteren 0x00-Bytes sind nur Füllmaterial für ggf. längere Teilenummern. Es verbleiben also diese, reinen Antwortbytes:
41 47 39 54 2D 31 34 41 30 37 33 2D 44 41

Jedes dieser Bytes entspricht einem Zeichen der ASCII-Tabelle. Mit Hilfe eines HEX zu ASCII-Converters erhält man dann folgendes Ergebnis:
AG9T-14A073-DA

Dies entspricht EXAKT der Beschriftung meines BCM!

Als nächstes mache ich mich daran die restlchen Sequenzen zu entschlüsseln. Ich vermute das nun der Bootloader folgt.

Hier mal, zur Veranschaulichung die von ELMConfig ausgewählte VBF-Datei mit dem Bootloader für mein Mondeo Labor-BCM:

AG9T-14C097-AC.vbf

vbf_version = 2.2;


header {
    //**********************************************************
    //*
    //*                  Volvo Car Corporation
    //*
    //*     This file is generated by VBF CONVERT ver. 3.2.0
    //*
    //*                        DO NOT EDIT !
    //*
    //**********************************************************


       description = {
         "VO10BC_BL_V10_03.05 - Ford Secondary Bootloader (SBL)"
       };


    // Volvo software part number
       sw_part_number = "AG9T-14C097-AC";


    // Volvo software part type: Secondary bootloader
       sw_part_type = SBL;


    // Network: CAN high speed main network
       network = CAN_HS;


    // main node with ECU description: BCM - Body Control Module
       ecu_address = 0x726;


    // 11-bit CAN identifiers
       frame_format = CAN_STANDARD;


    // Call address
       call = 0x00000410;


    // Blocks:   3
    // Bytes:    11186


    file_checksum = 0x22F035C5;
}<AB HIER FOLGEN DANN NAHTLOS DIE BINÄRDATEN BIS ZUM ENDE DER DATEI>

Das meiste ist selbsterklärend, denke ich. Hier wird die Node-ID und der Bus eingestellt, über den das "Zielgerät" erreichbar ist:

// Network: CAN high speed main network
 network = CAN_HS;


// main node with ECU description: BCM - Body Control Module
 ecu_address = 0x726;

Auf das CAN-Bus Format ist klar:

// 11-bit CAN identifiers
 frame_format = CAN_STANDARD;

Interessant ist dieser Teil mit der "Startadresse" des Bootloaders:

// Call address
 call = 0x00000410;

Hier wird der uC auf dem BCM mit der Programmausführung beginnen.

Wie diese Checksum verwendet wird ist mir noch nicht klar:

file_checksum = 0x22F035C5;

Ob die für die VBF-Datei ist, oder mit dem Bootloader übertragen wird. Keine Ahnung. Finden tue ich diese Sequenz jedenfalls nicht in der Übertragung zum BCM.

Die Binärdaten könnte man über einen HEX-Editor extrahieren und mit einem geeigneten Disassembler, naja "lesbar" machen. Aber Assembler ist harter Tobak und ohne genaue Kenntnis des Chips und der Peripherie wird man daraus nicht schlau. Darin wird praktisch nur über "Nebeneffekte" etwas ausgelöst. D.H. irgendein Bytewert wird an irgendeine Speicheradresse geschrieben und eine andere Hardwarekomponenten wird dann deswegen einen IO-Pin abfragen oder setzen. Versuchen werde ich es trotzdem mal, denn es müssten sich auch interessante Dinge darin finden lassen

Die Datenübertragung habe ich schon größtenteils analysiert und, oh Wunder, dieser gesamte Binärteil wird komplett zum BCM übertragen. Gleich darauf folgt die gesamte CCC (exakt so wie es im *.elm File drin steht).
Hierzu wird sowas wie ein "Sicherheitsschlüssel" ausgetauscht und ein "Download" vorgenommen. Genaueres schreibe ich, sobald ich meine alle Kommunikationen interpretiert zu haben. Leider ist vieles dafür reiner "Ford-Kram" und entspricht nicht dem OBD-Standard. Da sind die Informationen sehr rar...

Inzwischen hab ich aber auch erkannt das FORscan das deutlich fortschrittlichere und umfangreichere Programm ist, im Vergleich zu ELMConfig. Aber das diskutier ich ein Andermal...

Sehr interessant! Ja, das mit der Prozessorvielfalt stimmt wohl, war aber auch zu erwarten.
IDA kenne ich noch nicht, hab es aber gefunden. Da gibt es eine Non-Commercial Freeware, aber nur bis Version 5.0 und eine aktuelle Eval mit der man aber nur 80x CPUs und keine Embedded uC kann