Ich führe den Threadstrang von hier
Beitrag "Re: 93C66 Tacho Datei" in
diesem Thread mal weiter, sonst ist es thematisch zu durcheinander :-)
Also, was ich noch festgestellt habe ist, das wenn man z.B. "4.2 km" auf
dem Tageszähler hat und dann den Tacho stromlos macht und wieder
anklemmt, hat man "4.0 km" drauf!
Das bedeutet das nicht ständig ins EEPROM geschrieben wird, sondern wohl
nur "volle Kilometer".
Aber, wie man auf dem Foto sieht, wird intern ein Fließkomma-Wert
gespeichert, mit zwei Nachkommastellen! Auch interessant... womöglich
muss man das errechnete Ergebnis noch durch 100 teilen :-)
Habe auch mal ein Diff zwischen den einzelnen EEPROM Inhalten bei
veränderter Kilometerzahl erstellt und hier als Bild beigefügt.
Zum Thema MAC7116 habe ich hier in meinem Wiki mal so einiges
zusammengetragen: https://mk4-wiki.denkdose.de/artikel/ipc/mac7116
Interessant ist, das bei jeder Änderung etwas andere Bytes ihren Wert
ändern. Hier mal gelb hinterlegt was sich bei jeder KM-Änderung
inhaltlich verändert.
>Also, was ich noch festgestellt habe ist, das wenn man z.B. "4.2 km" auf>dem Tageszähler hat und dann den Tacho stromlos macht und wieder>anklemmt, hat man "4.0 km" drauf!>Das bedeutet das nicht ständig ins EEPROM geschrieben wird, sondern wohl>nur "volle Kilometer".
Da sind wohl die 1 Million Write Cycle der begrenzende Teil.
Ich werde immer noch nicht das Gefühl los das er irgendeine Checksumme
im Prozessor Ram vorhält wo ja auch die Nachkommastellen liegen dürften.
Oder über deine Daten auf dem Can Bus kommt noch irgend was nicht
gewolltes mit.
Ich hatte heute noch die Idee deine Daten auf einen 24c16 zu schreiben
und zu einem Kumpel zu fahren. Der hat einen Programmer um am Mondeo 4
den km Stand zu ändern. Dann wüsste man was die "professionellen
Programmer" da so tun. Leider scheitert es an dem nicht vorhandenen
24C16 und der Zeit nach Holland zu fahren.
Gruß Rene
Wow, so viel Einsatz, ich bin beeindruckt! :-)
Ich war auch nicht faul, wenn auch leider bislang erfolglos. Ich habe
mich etwas eingelesen und geschaut wie andere das so machen, aber nichts
passte so richtig.
Nach dem Ergebnis des Vergleichs sieht es ja eher so aus, als wäre der
Zählerstand nicht in den ursprünglich genannten Bytes zu finden, sondern
etwas daneben, denn diese sich 5mal wiederholenden Bytes "79 D9" bleiben
über alle readouts gleich.
Oft wird wohl auch eine Negation als eine Art Checksumme verwendet. Also
wenn der Bytewert z.B. 0x33 0x5A ist, dann steht dahinter gleich 0xCC
0xA5. Man muss also beide Bytes entsprechend ändern damit es akzeptiert
würde. Aber solche Kombinationen konnte ich im EEPROM nicht finden.
Dann liest man auch immer wieder mal was über einen XOR mit 0xFF. So ein
Unsinn, das ist doch im Endeffekt auch nur eine Negierung der Bits.
Naja, steht sich auch viel Mist im Netz ;-)
Zusätzlich gibt es wohl auch noch weitere Prüfsummen irgendwo versteckt.
Wie auch immer, die Frage ist ja hauptsächlich nach der Codierung des
eigentlich dezimalen Kilometerstandes. Aber, wie wir beim Convers
gesehen haben ist er nicht integer, sondern float ("249.506,59" war ja
im TEST-Modus des Convers+ zu lesen). Dort lese ich auch was über einen
"NVM EEPROM lvl: ZB" und einen "ROM lvl: ZB". Sicher muss das EEPROM vom
Inhalt her mit dem ROM (ich nehme an das damit die Firmware des Convers
gemeint ist) zusammenpassen.
Die KM-Zahl wird dann oft mal 16 genommen, was Bittechnisch ein
Left-Shift-4 ist. Ich hatte dann mal versucht das Bitpattern der
integeren und der float Kilometerzahl im EEPROM zu finden. Erfolglos.
Es ist auch die Frage ob da wirklich der Gesamt-KM Stand als Zahl
abgelegt ist, oder irgendwie anders. Ich finde bei anderen ODOs auch,
das die Tausender und die Hunderter getrennt abgelegt werden. Also hätte
man 249 und 506 zu kodieren. Da es bis 999 pro Block gehen kann, reichen
2 Byte dafür völlig aus.
Zuletzt wissen wir nun auch das der Tageskilometerzähler (das Convers
hat nur einen) auch abgelegt wird, jedoch als Ganzzahl. Nur im RAM wird
ein Kommawert gespeichert. Nach einem Strom Aus/An ist der Nachkommawert
nämlich weg. Wir wissen auch das jeder Kilometer, also nicht nur die
geraden oder ungeraden gespeichert wird.
Aufgefallen ist mir auch, das Gesamt- und Tageskilometerzähler nicht
synchron auf 0 laufen. Sprich, hat der Tageszähler z.B. 5,4km erreicht,
kann es sein das der Gesamtzähler schon zum nächsten KM umspringt.
Im Internet habe ich so einige Online-Editoren gefunden und dieser ist
ganz brauchbar: https://hex-works.com/eng
Darüber hinaus habe ich mir zum testen mal zahlreiche für Windows
heruntergeladen. Ich hätte halt gern einen schönen, schnellen Diff
zwischen mehreren Binaries. Das können nicht alle, bzw. viele können nur
zwei gleichzeitig vergleichen.
Also, ich schnüffle weiter und bin für jede Idee offen :-)
>Wow, so viel Einsatz, ich bin beeindruckt! :-)
Naja, es wäre ja ein Ausflug mit meinem Japanischen "Suizid-Renner"
geworden.
Das grenzt ja scharf an Urlaub. ;-)
Auf den Bildern sieht man den Output der Datenbank. Das passt ja mal
genau zu deinen beobachteten Änderungen im EEprom. Und wenn die einen IC
benutzen dann brauchen die den auch. Ansonsten hätte der BWL-er dafür
gesorgt das er ersatzlos gestrichen wird. Hast du die Platine
genauestens von beiden Seiten nach weiteren IC abgesucht? Nicht das da
irgendwo ein Shadowram mit Goldcap sitzt.
>Dann liest man auch immer wieder mal was über einen XOR mit 0xFF.
Das hat man schon mal bei Checksummen pro 15 Bytes. Da geht es 0xFF ^
Byte1 ^ Byte2 ^ .... ^ Byte15 und das Ergebniss landet in Byte16.
BMW(VDO) hat da z.B Spass dran.
Gut wären halt mal Dumps von KM Ständen mit 2, 4, 8, 16, 32, 64 ... km
mehr. Was genau sendest du über Can an das Ki? Ein Datensatz oder
mehrere?
Wie ist der Aufbau? Da wäre mehr Input schön.
Ja die Hex Editoren/Viewer sind so ein Ding. Stört mich auch immer ein
wenig. Vieleicht sollte man sich da mal was programmieren.
Gruß Rene
Erklär doch bitte mal wie Du zur Tabelle in Bild zwei.jpg gekommen bist?
Welche CAN IDs den Tacho veranlassen die KM-Zähler zu erhöhen ist mir
bislang nicht bekannt, bin gerade dabei das rauszufinden. Ich hätte
geglaubt das hier entweder ein KM-Stand vom BCM kommt, oder ein Delta
oder es gibt irgendwelche Impulse von den Radsensoren.
Wie der CAN-Bus im Mondeo tickt habe ich hier im Wiki recht umfangreich
beschrieben: https://mk4-wiki.denkdose.de/artikel/can-bus/start
Änhliches für den/die Tachos:
https://mk4-wiki.denkdose.de/artikel/ipc/start
In Kurzform ist es so, das der Tacho am MS-CAN Bus hängt und den MM-CAN
Bus (Multimedia) generiert. Interessant für den Tachostand ist nur der
MS-CAN. Hierin hängen üblicherweise keine Komponenten vom Motor und
Fahrwerk, die sind im HS-CAN. Das Gateway ist dabei die
Zentralelektrikbox (BCM). Die Nachrichten-IDs die ein BCM sendet sind
mir wohl bekannt, nicht jedoch ALLE Inhalte und Formate, aber doch so
einige. Ich weiss das dort ein Kilometerstand ausgegeben wird, aber
dieser wird vom Tacho ignoriert und dient vermutlich eher anderen
Modulen. Dieser Tachostand kann vom den des Kombiinstrumentes abweichen,
sprich das KI macht sich seine eigene Sicht auf die Welt, teilt diese
aber mit keinem, das wiederrum macht das BCM aber.
Es gibt also irgend ein anderes Signal (ID) aus dem sich der Tacho den
KM-Stand abliest. Was ich nun tue ist die Nachrichten-IDs aus einer
Aufzeichnung des MS-CAN während einer Fahrt immer weiter zu reduzieren
bis nur noch die übrig bleiben, welche die gesuchte Information
enthalten. Zuerst werfe ich dafür alles bereits bekannte raus. Dann
entferne ich nach dem Binärbaum-Prinzip die untere Hälfte aller übrig
gebliebenen IDs. Ändert sich der Tachostand dann nicht, ist das Signal
vermutlich in der oberen, rausgefilteren Hälfte. Dann machte dort
dasselbe. Nach vier bis fünf Iterationen sollte man das Ergebnis haben.
Das klingt einfach, ist aber sehr zeitaufwändig. Bin halt dran :-)
Sobald ich also eine beliebige Wegstrecke simulieren kann (und das
hoffentlich schnell, so als würde ich 240 km/h fahren. Zuviel geht
vermutlich in einem Plausibilitätscheck unter und wird als Fehler
interpretiert) kann ich beliebige KM-Zwischenstände aus dem EEPROM
auslesen.
Alternativ könnte ich auch einen LA an die Pins hängen und schauen wann
sich da was tut. Eigentlich sollte ja nur zu bestimmten Intervallen
schreibend darauf zugegriffen werden. Nach dem Powerup sollten das fast
nur noch die Änderungen der KM-Stände sein.
Hi,
>Erklär doch bitte mal wie Du zur Tabelle in Bild zwei.jpg gekommen bist?
Man kann die km in die Datenbank(Script/Programm) eingeben und erhält
die zu schreibenden Werte. Das passt nicht immer auf den km genau aber
man ist nahe dran. So was ähnliches wie dieses kostenpflichtige
Onlineangebot: www.tachosoftonline.com
>Zuerst werfe ich dafür alles bereits bekannte raus. Dann>entferne ich nach dem Binärbaum-Prinzip die untere Hälfte aller übrig>gebliebenen IDs. Ändert sich der Tachostand dann nicht, ist das Signal>vermutlich in der oberen, rausgefilteren Hälfte. Dann machte dort>dasselbe. Nach vier bis fünf Iterationen sollte man das Ergebnis haben.
Klingt nach einem Plan.
>Alternativ könnte ich auch einen LA an die Pins hängen und schauen wann>sich da was tut. Eigentlich sollte ja nur zu bestimmten Intervallen>schreibend darauf zugegriffen werden. Nach dem Powerup sollten das fast>nur noch die Änderungen der KM-Stände sein.
Ja so habe ich das damals gemacht.
Gruß Rene
So, habe das für den Kilometerzähler zuständige Byte lokalisiert :-)
Es steckt in ID 040 des MS-CAN auf Position D6 (wenn man D0 als zuerst
empfangenes Byte einer Nachricht sieht und die Bytes von rechts nach
links aufbaut, also D7..D0). Nur dieses Byte sorgt dafür das sich der
Kilometerzähler ändert. Das kann ich nun 100% bestätigen, weil ich auch
den Umkehrtest gemacht hab, also das Byte im CAN-Log statisch auf 00
gestellt und diesen abgespielt. Laut Tacho fährt das Fahrzeug ca. 50
km/h aber der Kilometerzähler ändert sich nicht mehr.
Was mir noch nicht klar ist, sind die darin befindlichen Daten (siehe
angefügte Datei). Die sind aufsteigend, wobei die Differenz zu schwanken
scheint. Sendet man einen statischen Wert (egal welchen) verändert sich
der Tachostand nicht. Das IPC prüft also ob dort eine Differenz
erkennbar ist.
Die ID wird im Intervall von 50ms vom BCM ausgesendet. Gut möglich das
dies eine Entfernungsangabe ist und man davon ausgeht das sich zwischen
zwei Intervallen keine größere Entfernung ergeben kann als durch ein
Byte darstellbar. Was auch immer das dann für eine Größe ist (mm, cm,
Radumdrehungen, Takte des Radsensors, whatever).
Ok, ich denk ich habs. Die Schrittweite zwischen den Bytewerten ist
repräsentativ für die Geschwindigkeit. Sprich, je kleine die Schritte
desto langsamer ändert sich der Kilometerstand, je größer die Schritte
umso schneller.
Dazu habe ich mir einen kleinen Tacho-Generator programmiert der solche
Traces zum abspielen für CANHacker generiert und werde mal experimentell
ermitteln wie groß die Schritte maximal sein dürfen. Theoretisch max.
0xFF, also z.b. immer ein Wechsel von 0x00 auf 0xFF. Dann hätte man laut
Tacho vermutlich fast Schallgeschwindigkeit ;-))))
Hier mal die Unterschiede aufgezeigt. Was mich irritiert ist das die
Bytes, welche laut den KM-Berechnungstools den Kilometerstand beinhalten
sollten, sich garnicht verändern...
Vielleicht interpretieren wir das immer noch falsch und die Änderungen
sind garnicht in diesen Bytes?
Ich werde mal noch ein paar KM mehr abspulen, wenn auch sicher keine
1000, das dauert auch bei meiner Methode ewig...
Womöglich sind die beiden Bytes 79 D9 nur für die Tausender-Stellen
(Major) und darunter (Minor) sind in den Bytes "daneben" ?
Jedenfalls kann ich weder in den Bytes eines KM-Standes, noch dazwischen
irgendwelche logischen Zusammenhänge erkennen.
Hi,
>Vielleicht interpretieren wir das immer noch falsch und die Änderungen>sind garnicht in diesen Bytes?
Alle 128 km sollte sich da was ändern. Siehe Anhang. Die Daten kommen
aus der Datenbank.
Gruß Rene
Du hattest recht Rene, nun hat sich auch eine der sonst statischen Bytes
"bewegt". Anstelle "79 D9" steht dort nun "79 E0".
Das spricht doch dafür das es einen Major und Minor Teil gibt?!
Oder arbeiten die dort mit einem Basiswert und einem Offset?
Ich glaub ich schließ jetzt mal nen LA an das EEPROM, spiele dem IPC
Bewebung vor und schaue wann sich am EEPROM was tut. Laut unserer These
sollte das frühestens dann der Fall sein, wenn einer der Zähler im RAM
einen Übertrag auf den nächsten Kilometer erfährt.
Von der Logik her ist ja doch klar das beim Start des IPC der KM-Wert
aus dem EEPROM ins RAM gelesen und von dort aus am Display angezeigt
wird. Es ändert sich fortan nur der Wert im RAM bis zu dem Zeitpunkt zu
dem ein KM voll ist und dies dann ins EEPROM geschrieben wird. Das haben
wir am Tageskilometerzähler gesehen, der, wenn man das IPC stromlos
macht immer einen vollen Wert hat, also die Nachkommastelle fehlt. Dabei
wird aber wohl gerundet, sprich unter 0.5 km wird abgerundet und darüber
aufgerundet. Also speichert das IPC vielleicht sogar alle 0,5 km ab.
Laut dem ersten LA-Log, welcher die 10s nach einschalten des IPC
enthält, passiert folgendes:
(die Zeilenangaben referenzieren auf die TXT-Datei mit dem
Analyzer-Export des LA-Log)
Der uC liest zunächst von Speicherstelle 0x0D ein Byte. Hier hat es den
Wert 0x05. (Zeile 1 - 4)
Das dient womöglich zur Verifikation der EEPROM Daten oder nur darum
festzustellen das ein EEPROM da ist.
Muss mal ausprobieren was passiert wenn ich diesen Wert ändere.
Anschließend wird der Inhalt des EEPROM eingelesen. Zunächst nur der
Bereich 0x000 bis 0x698 (Zeile 5 - 1692)
Danach folgt etwas interessantes ab Zeile 1693:
1.132867250000000,4,0xAE,0x10,Write,ACK
1.132932916666667,5,0xAF,0x00,Read,ACK
1.132962583333333,5,0xAF,0x2B,Read,ACK
0xAE ist das Adress-Byte. Die ersten 4 Bits davon sind fix, 1010xxxx.
Das niedrigste Bit bestimmt ob es sich um eine Read oder Write Operation
handelt, 1010xxxD. Die übrigen Bits sind die Device-Address-Bits vom
I2C-Bus. Die externen Pins A0-A2 sind auf GND gelegt und damit wird dann
die Page gesteuert auf die zugegriffen wird. Jede "Page" ist dabei 256
Bytes (0xFF) groß. So dort oben wird auf Page 7 zugegriffen, mit Offset
von 0x10, was dann der Adresse 0x710 entspricht.
Die Daten die dort kommen befinden sich also im EEPROM ab Adresse 0x710
bis zum Ende 0x7FF (240 Bytes) (Zeile 1694 - 1933)
Danach, ab Zeile 1934 wiederholt sich das Spiel. Zunächst wird bis Zeile
3624 wieder der Inhalt von Adresse 0x0D und danach der Anfang des EEPROM
gelesen. Anschließend kommt wieder der Teil vom "Schatten"-EEPROM bis
Zeile 3865.
Nun folgt eine kleine Variante und zwar wird an die Adresse 0x1C das
Byte 0xFF geschrieben und direkt danach ausgelesen:
1.199004333333333,12,0xA0,0x1C,Write,ACK,
1.199034666666667,12,0xA0,0xFF,Write,ACK
1.200106166666667,,0xA0,,Write,NAK
1.201184166666667,14,0xA0,0x1C,Write,ACK
1.201250166666667,15,0xA1,0xFF,Read,NAK
Dann wird ab Zeile 3872 wieder das EEPROM gelesen, allerdings in kleinen
Portionen. Sieht so aus als würde der uC nun geziehlt bestimmte
Speicherstellen einlesen in dem für ihn relevante Parameter stehen. Das
geht bis Zeile 4152. Da der übermittelte Adresswert nur 8 Bit groß ist,
kann er auch nur die ersten 255 Bytes damit adressieren.
Weiter bin ich bislang noch nicht gekommen... es folgend noch einige
interessante Write-Operationen. Was man aber an den LA-Logs sieht ist,
das das Convers ständig mit dem EEPROM kommuniziert. In dem "1km" Log
habe ich den Punkt noch nicht gefunden wo der geänderte KM-Stand
zurückgeschrieben wurde.
Hallo,
leider ist die Zeit im Augenblick knapp. Alle Kunden wollen eine
Klimawartung. Komisch, kann ich garnicht verstehen. ;-)
Ja der 24C16 verhält sich so wie 8 x 24C02 mit den entsprechend
gesetzten Adressleitungen. Erst wird per Write Befehl die Adresse
gesetzt und dann auf das nun adressierte Byte entweder schreibend oder
lesend zugegriffen.
Dabei ist:
x = r/w
0x000 = 0b1010000x
0x100 = 0b1010010x
0x200 = 0b1010100x
0x300 = 0b1010011x
0x400 = 0b1010100x
0x500 = 0b1010101x
0x600 = 0b1010110x
0x700 = 0b1010111x
Man müsste sich da mal einen Parser programieren der die Zeilen aus
Saleae Logic in ein besser lesbares Format umwandelt. Wollte ich immer
schon mal machen. Muss mal schauen. Es sind einfach zu viele Daten.
Sowas wie
Write Adresse: 0x000 Daten: 0x47 0x11
Read Adresse : 0x710 Daten: 0x22 0x33 0x44
Dann mal eine Weile laufen lassen und nach wiederkehrenden Sequenzen
suchen. Der Zugriff auf den EEprom wird ja immer nach dem gleichen
Muster erfolgen. Da sollte sich schnell was herauskristallisieren.
Gruß Rene
Die Berechnung des Kilometerstand erfolgt mit einer Auflösung von 200
Meter, es werden dafür 20 Bytes im EEPROM ab Offset 0x774 verwendet. Die
20 Bytes sind fünf Einträge mit jeweils 4 Bytes, jeder Eintrag ist mit
einer 4-Bit CRC und einem Parity Bit gesichert. Pseudo-Code wie die
Berechnung des Kilometerstand aussehen könnte ist angehängt, das
Ergebnis passt für die Beispiel-Daten von weiter oben (249.510 km bzw.
249.516 km), etwas anderes habe ich nicht ausprobiert. Ich denke dass
das so passen könnte, man sollte es aber mit weiteren Beispiel-Daten
ausprobieren um sicher zu sein.
Hi,
habe es gerade mal durch VisualStudio C++ gejagt. Den dritten KM Stand
habe ich auch mit reingenommen. Und es sieht gut aus.
@Dieter: Darf ich Fragen wie du vorgegangen bist?
Gruß Rene
Ich werde das mal testweise aufs IPC applizieren, aber ich ich muss
schonmal sagen das ihr beide echt genial seid!! :-)
"Leider" habe ich Urlaub und bin bis kommende Woche nicht in der lage
das zu testen, aber ich kann es kaum erwarten. Ich denke ich werde auch
noch einen Tag brauchen um das zu kapieren wie Dieter es beschrieben
hat.
Rene Z. schrieb:> @Dieter: Darf ich Fragen wie du vorgegangen bist?
Ich habe es mir in der Firmware angesehen. Im EEPROM steht die
Software-Bezeichnung, anhand dieser kann man sich die Update-Datei über
UCDS holen. Da es so einfach ist an die Firmware zu kommen und ARM-Code
recht gut zu lesen ist habe ich einfach mal geschaut wie schnell man
sich darin zurechtfindet.
Dieter schrieb:> Die Berechnung des Kilometerstand erfolgt mit einer Auflösung von 200 Meter
Wie kommt ein Hersteller nur auf solche Werte? Warum ausgerechnet 200
und nicht 100 Meter? Komisch.
Und wie kommt es dann zu der KM Anzeige im Testmodus des Covers+, in der
eine zweistellige Nachkommazahl mit "xxx,76" zu sehen ist?
Dieter schrieb:> Ich habe es mir in der Firmware angesehen.
Ohja, die hätte ich auch gleich hier verlinken können, daran hatte ich
garnicht gedacht, wahr voll im "EEPROM-Tunnel" ;-)
> und ARM-Code recht gut zu lesen ist habe ich einfach mal geschaut wie schnell
man sich darin zurechtfindet.
Ich wünschte das könnte ich auch. Hab bislang keinen Plan wie ich an die
Nummer rangehen soll. Kann man bei Dir ne Schulung buchen?! Oder dich
mal zu einem Wochenende einladen? ;-)))
Meinen allergrößten Respekt, wir werkeln hier tagelang umeinander und Du
schaust mal eben in den Code... aber trotzdem wieder viel gelernt!
Olli Z. schrieb:> wir werkeln hier tagelang umeinander und Du> schaust mal eben in den Code
Ganz so einfach ist es nicht, ein paar Stunden braucht es schon um sich
bei einer Firmware ohne weitere Hilfestellung zurechtzufinden (z.B.
Strings oder Debug-Ausgaben, die Hinweise auf die Funktion des Codes
geben) und ARM Assembler sollte man natürlich auch lesen können. Das ist
entfernt vergleichbar mit Kreuzworträtsel lösen, am Anfang hat man fast
nichts, wenn dann die ersten Funktionen identifiziert sind geht es immer
schneller.
Hi,
ich habe heute noch mal draufgeschaut. Es gilt ja das vom jeweils
vierten Byte die unteren 7 Bit auch die unteren 7 Bit vom KM Stand sind.
Mit dem achten Bit wird die Parity auf ungerade gestellt. Und wenn man
schaut ergeben die unteren 7 Bit eine fortlaufend Zahl. Also 0,1,2,3,4
oder 1,2,3,4,5 oder 2,3,4,5,6 ... 123,124,125,126,127. Damit wäre der
kleinste darstellbare KM Stand 4 km. 0 + 1 + 2 + 3 + 4 = 10 / 5 = 2 + 2
= 4 . Was mich dazu bringt das folgender KM Stand eigentlich ungültig
ist obwohl CRC und Parity stimmen:
Das werde ich selbstverständlich gern testen! Bin aber erst Dienstag
wieder zuhause, daher dauert das Feedback etwas.
Aber, wie kommst Du auf +2 ? In Dieters Formel steht doch +1
Im EEPROM gibt es noch einen weiteren Eintrag mit Bezug zum
Kilometerstand: Hinter den bereits bekannten 20 Bytes steht ab Offset
0x788 ein DWORD (32-Bit, Big-Endian). Das DWORD ist mit einer 4-Bit CRC
in den obersten 4 Bit geschützt (die bereits beschriebenen CRC
Berechnung, nur diesmal über die untersten 24 Bit des Werts).
Ein Beispiel aus einem der EEPROM Dumps:
0x788: 31 7C B5 86 -> DWORD 0x317CB586
CRC: 0x3, Wert ohne CRC 0x017CB586, dezimal 24950150
Wann genau dieser Eintrag im EEPROM aktualisiert wird müsste man
ausprobieren .
Sehr interessant! Denn das ist genau das was im TEST Modus des IPC als
Fließkommazahl mit zwei Stellen angezeigt wird. Ich werde man nach einem
Write auf diese Speicherstelle suchen. Das müsste im LA Dump ja zu
erkennen sein.
Olli Z. schrieb:> Wie könnte das denn kommen das an 0x788 einmal der Gesamt und> einmal der Tageskilometerzählet steht?
Verstehe die Frage nicht. Es steht an 0x788 der Gesamtkilometerstand.
Aber nicht sehr aktuell.
Die letzten vier habe ich mit Taschenrechner und Hexeditor erstellt.
Gruß Rene
So, konnte es kaum abwarten und musste gleich nochmal ran und
ausprobieren und siehe da - ALLE von Dir errechneten Kilometerstände
funktionieren, inkl. dem 0er :-)))
Dennoch bemerkenswert: Wir haben ja nur den Gesamtkilometer geändert,
aber der Tageskilometerzähler hat sich jeweils mit zurück auf 0.0
gestellt. Auch der im TEST-Modus ist 0.
Rene schrieb:> Olli Z. schrieb:>> Wie könnte das denn kommen das an 0x788 einmal der Gesamt und>> einmal der Tageskilometerzählet steht?>> Verstehe die Frage nicht. Es steht an 0x788 der Gesamtkilometerstand.> Aber nicht sehr aktuell.>> Die letzten vier habe ich mit Taschenrechner und Hexeditor erstellt.
Sorry, Rene, das habe ich falsch interpretiert. Vergiss meine Frage
einfach ;-)
Rene Z. schrieb:> ich habe heute noch mal draufgeschaut. Es gilt ja das vom jeweils> vierten Byte die unteren 7 Bit auch die unteren 7 Bit vom KM Stand sind.> Mit dem achten Bit wird die Parity auf ungerade gestellt. Und wenn man> schaut ergeben die unteren 7 Bit eine fortlaufend Zahl. Also 0,1,2,3,4> oder 1,2,3,4,5 oder 2,3,4,5,6 ... 123,124,125,126,127.
Ich denke das KI wird die Fünf Speicherstellen immer schön nacheinander,
rotierend nutzen, also alle 200 Meter, um die maximal Anzahl
Schreibzyklen zu verteilen und somit garantier 1 Million KM auf dem KI
speichern zu können.
Stephan schrieb:> Wozu eigentlich das Ganze? Euch ist sicher klar das der km Stand> mehrfach im Auto verteilt herum liegt.
Um ein gebraucht gekauftes Kombiinstrument vom Schrott an den
Kilometerstand des Fahrzeuges anzupassen. Neu gekaufte stellen sich von
selber, und alles andere wäre ohnehin illegal.
Wundert mich ohnehin, dass die OEMs den Kilometerstand nicht
"verschlüsselt" ablegen. XOR 55AA oder ROT13 würde ja schon reichen.
Dann wäre das ein "Kopierschutz", den zu "umgehen" strafbar wäre.
Nachdem ich mich etwas mit IDA Pro beschäftigte, habe ich mir die IPC
Firmware mal vorgenommen und über die IO-Adresse 0xFC0A 0000 dort auch
Funktionen für das I2C Handling identifiziert und soweit verstanden :-)
Diese liegen im Bereich des PBL, also unterhalb 0x0000 5000.
Das verrückte ist nur das diese Funktionen scheinbar garnicht verwendet
werden?! Ich habe Breakpoints auf sämtliche dieser Funktionen gelegt und
bis auf die Initialisierungsroutine die lediglich das I2C-Modul
aktiviert wird keiner der BPs aktiviert.
Ich habe es mit mit dem Segger J-Link Commander gemacht (damit habe ich
den PBL auch ausgelesen), danach dann mit 'r' einen Soft-Reset
ausgelöst, aber die Funkionen werden nicht aufgerufen, was ja eigentlich
garnicht sein kann...
Da das RAM beim Soft-Reset seinen Inhalt behält habe ich es dann noch so
versucht: CPU Halt, RAM mit 0x00 überschreiben, PC auf 0 setzen und CPU
starten. Aber auch nix.