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
Angehängte Dateien:
:
Bearbeitet durch User
Angehängte Dateien:
-
eeprom_diffs.jpg
49 KB
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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 ;-))))
:
Bearbeitet durch User
Angehängte Dateien:
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.
Angehängte Dateien:
-
drei.jpg
38 KB
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
:
Bearbeitet durch User
Anbei nun eine Datei mit dem Kilometerstand 249.648 (Tageszähler 146.5).
Angehängte Dateien:
-
diff_249503-zu-249648.jpg
320 KB
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
Wurdest Du denn aus dem EEPROM mit den 128km mehr schlauer bezüglich der Kodierung?
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.
Angehängte Dateien:
-
vier.jpg
94 KB
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
:
Bearbeitet durch User
Angehängte Dateien:
-
fuenf.jpg
67 KB
Hi, habe nun alle bekannten Km Stände getestet:
1 | 249503
|
2 | 249504
|
3 | 249505
|
4 | 249510
|
5 | 249516
|
6 | 249648
|
Bei allen ist das Ergebnis korrekt.
:
Bearbeitet durch User
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:
1 | 0, 0, 0, 0, 0 = 0 / 5 = 0 + 2 = 2 km |
2 | 0x774: 0x00 0x06 0xFF 0x80 0x00 0x06 0xFF 0x80 0x00 0x06 0xFF 0x80 0x00 0x06 0xFF 0x80 0x00 0x06 0xFF 0x80 |
Diese hier wären dann gültig:
1 | 0, 1, 2, 3, 4 = 10 / 5 = 2 + 2 = 4 km |
2 | 0x774: 0x00 0x06 0xFF 0x80 0x00 0x06 0xFF 0x01 0x00 0x06 0xFF 0x02 0x00 0x06 0xFF 0x83 0x00 0x06 0xFF 0x04 |
3 | |
4 | 1, 2, 3, 4, 5 = 15 / 5 = 3 + 2 = 5 km |
5 | 0x774: 0x00 0x06 0xFF 0x01 0x00 0x06 0xFF 0x02 0x00 0x06 0xFF 0x83 0x00 0x06 0xFF 0x04 0x00 0x06 0xFF 0x85 |
6 | |
7 | 2, 3, 4, 5, 6 = 20 / 5 = 4 + 2 = 6 km |
8 | 0x774: 0x00 0x06 0xFF 0x02 0x00 0x06 0xFF 0x83 0x00 0x06 0xFF 0x04 0x00 0x06 0xFF 0x85 0x00 0x06 0xFF 0x86 |
Jetzt wäre es nicht schlecht mal zu sehen was das KI wirklich anzeigt. Gruß Rene
:
Bearbeitet durch User
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
Morgen,
>Aber, wie kommst Du auf +2 ? In Dieters Formel steht doch +1
Ja da steht erst mal:
1 | calc_mileage(g_ubMileage_249510) / 5 + 1 |
aber in der Funktion get_mileage_entry_and_check_parity() wird hier:
1 | return (ub & 0x7F) + 1; |
noch 5 x 200 meter aufaddiert. Über die Funktion get_parity hab ich auch ein wenig gegrübelt. Was passiert denn da genau?
1 | uint8_t get_parity(uint8_t ub){ |
2 | uint8_t ubParity = 0; |
3 | while (ub != 0){ |
4 | ubParity++; |
5 | ub &= (ub - ubParity); |
6 | }
|
7 | return ubParity & 0x01; |
8 | }
|
Bis ich dann drauf gekommen bin das sie nichts anderes als
1 | uint8_t get_parity(uint8_t ub) |
2 | uint8_t i = 0x80, p = 0; |
3 | While (i){ |
4 | If (ub & i) // check high of all bit position |
5 | p + 1; |
6 | i >>= 1; |
7 | }
|
8 | Return p & 0x01; |
9 | }
|
macht. Allerdings ist sie effizienter. Gruß Rene
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
sechs.jpg
76 KB
Hi, ich hab das Programm um die zusätzliche Ausgabe und CRC Berechnung ergänzt. Gruß Rene
Wie könnte das denn kommen das an 0x788 einmal der Gesamt und einmal der Tageskilometerzählet steht?
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
Angehängte Dateien:
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.
:
Bearbeitet durch User
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.
Wozu eigentlich das Ganze? Euch ist sicher klar das der km Stand mehrfach im Auto verteilt herum liegt.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.