CCC programmer

  • Wenn meine Frau alleine im Auto sitzt, würde sie gern das Auto abschließen nachdem ich ausgestiegen bin.


    Dann verriegel doch einfach wenn du Aussteigst und mach die Innenraumüberwachung aus, wenn Sie raus will geht die Tür doch auf wenn Sie am Hebel zieht.

    Gruß Tom :fahrenlenkrad:


    ____________________________________________________________
    Dieser Beitrag wurde bereits 1.694.000 mal editiert, zuletzt von »digdog« (Heute, 01:96)

  • 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.

  • Wurde doch hier schon beschrieben wie das geht mit der LED. Die leuchtet sobald die Regenration läuft.


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

  • DTCs löschen könnte man ohne Probleme implementieren. Das diese aber durch eine geänderte CCC kommen muss nicht zwingend sein.


    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.


  • 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.


  • 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.

  • Zitat

    von Go4IT:
    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).


    Ja, habe KeyFree.
    Du meinst den kleinen Taster an der Fahrertür mit dem Schloss drauf?
    Der kann die ZV nur öffnen, nicht schließen.
    Der silberne Knopf zum Öffnen/Schließen geht ja per Bowdenzug zum Schloss. Und da wäre eben dass Ziel, von der Beifahrertür aus alles zu Öffnen/Schließen, wie es von der Fahrertür aus der Fall ist.
    Aber wie gesagt, eine einfache Lösung scheint es da wohl leider nicht zu geben.

    Mondeo Turnier 2.0 FFV Titanium, Thunder, ACC, IVDC, Bi-Xenon, KeyFree+PowerStart, Alarmanlage, Solarreflect, PDC vorn u. hinten, TPMS, Sitzklima, Luftqualitätsmesser+kühlbares Handschuhfach, Sony-6CD, Bluetooth-FSE incl. S&C, Außenspiegel anklappbar, silberfarbene Dachreling, Notrad incl. Wagenheber


    Selbsteinbau: Rückfahr- u. Front-Kamera mit 9" TFT-Monitor in der Sonnenblende, Ambiente-Beleuchtung in den Türgriffmulden, Rückstrahler an allen 4 Türen beleuchtet


    Baumonat 10/2008

  • Klingt zwar logisch, aber das hatte ich nach dem programmieren noch nie machen müssen.


    Nur im Versuchsaufbau oder auch am Fahrzeug nicht? Wenn ich Änderungen an der Konfig ins BCM und IPC schreibe muss ich danach immer eine Menge DTCs löschen (die waren vor dem Programmieren nicht da). Ist ja auch so im ElmConfig Thread beschrieben.

  • 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:


    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:


    Code
    1. 19,267 726 8 03 22 D1 00 00 00 00 00
    2. 19,268 72E 8 04 62 D1 00 02 00 00 00


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


    Code
    1. 19,891 726 8 05 27 02 B4 72 FD 00 00
    2. 19,892 72E 8 02 67 02 00 00 00 00 00


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


    Code
    1. 20,174 726 8 21 10 00 00 26 CA 00 00
    2. 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:

    Code
    1. 20,440 726 8 11 02 36 01 4C C8 45 C8
    2. 20,441 72E 8 30 00 00 00 00 00 00 00
    3. 20,456 726 8 21 3F EA AC FF BF 00 00
    4. 20,471 726 8 22 4D E8 3F EA 8C FF BF
    5. 20,486 726 8 23 00 00 4C E8 3F EA 2C
    6. 20,502 726 8 24 C7 2B 00 00 12 FA 01
    7. 20,518 726 8 25 B2 6C CB 00 00 00 B2
    8. 20,533 726 8 26 AC 00 B4 00 00 D6 08
    9. ...
    10. 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):

    Code
    1. 01,636 726 8 01 37 00 00 00 00 00 00
    2. 01,636 72E 8 03 7F 37 78 00 00 00 00


    Code
    1. 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:


    Code
    1. 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:


    Code
    1. 27,584 726 8 02 3E 80 00 00 00 00 00 -> BCM: Mode 0x3E (???)
    2. 27,847 726 8 03 22 F1 13 00 00 00 00 -> BCM: Diagnosedaten nach PID-Adresse 0xF1 (=Externe Diagnosetester)
    3. 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)
    4. 27,863 726 8 30 00 00 00 00 00 00 00 -> BCM: Mehrfach-Frames akzeptiert.
    5. 27,873 72E 8 21 54 2D 31 34 41 30 37 -> ELM: 2. Frame
    6. 27,883 72E 8 22 33 2D 44 41 00 00 00 -> ELM: 3. Frame
    7. 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! :thumbsup:


    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


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

    Code
    1. // Network: CAN high speed main network
    2. network = CAN_HS;
    3. // main node with ECU description: BCM - Body Control Module
    4. ecu_address = 0x726;



    Auf das CAN-Bus Format ist klar:

    Code
    1. // 11-bit CAN identifiers
    2. frame_format = CAN_STANDARD;


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

    Code
    1. // Call address
    2. call = 0x00000410;


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


    Wie diese Checksum verwendet wird ist mir noch nicht klar:

    Code
    1. 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...

  • Mit IDA kannst du die Dissamblen, funktioniert super, wenn du wissen willst was für ein Chip ist es kann ich es dir gerne mitteilen ;)

  • Für Convers kannst du ARM7 mit Little Endian nehmen ;) das Problem ist allerdings das jedes Steuergerät andere CPUs hat und daher andere Prozessoren.

  • 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 :-(

  • Aber falls du das Tool VBF Tool mal brauchst sag bescheid, das hilft dir den Binary Teil ganz easy vom ASCII Teil zu trennen, Checksummen und co... ✌️

  • Hallo zusammen!

    Ich Suche nach dem VBF Tool-Programm, nirgends in der öffentlichkeit. Teilen Sie bitte (private Nachricht).

    Danke!

  • Herzlich Willkommen hier im Forum und Grüße aus Heppenheim

    Wenn man tot ist, ist das für einen selber nicht schlimm, weil man ja tot ist ... schlimm ist es für die anderen .... genauso ist das übrigens wenn man doof ist! :D

  • OchTerminator, was willst du denn mit so ollem Kram? Du kommst doch aus der Zukunft, da braucht man so etwas doch höchstens für museale Zwecke.

    OH

    Die schnellste Verbindung zwischen zwei Punkten ist eine Gerade.
    Die von den meisten Fahrern am wenigsten beherrschte Strecke zwischen zwei Geraden ist eine Kurve.
    Was das heißt?


    Geradeaus sind wir alle schnell !!!


    Achtung! Beiträge können Ironie enthalten! Ironie unterliegt nicht der Kennzeichnungspflicht!


    Meine Beiträge in diesem Forum geben ausschließlich meine persönlichen Meinungen und Wissensstände wider.