Ford Tacho MAC7116 und 24C16

[Olli Z. (z80freak)]

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

[Olli Z. (z80freak)]

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.

[Rene Z. (renezimmermann)]

>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

[Olli Z. (z80freak)]

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

[Rene Z. (renezimmermann)]

>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

[Olli Z. (z80freak)]

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.

[Rene Z. (renezimmermann)]

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

[Olli Z. (z80freak)]

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

[Olli Z. (z80freak)]

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 ;-))))

[Olli Z. (z80freak)]

Hier dann nochmal zwei EEPROM-Dumps mit Differenz 16km

[Olli Z. (z80freak)]

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.

[Rene Z. (renezimmermann)]

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

[Olli Z. (z80freak)]

Anbei nun eine Datei mit dem Kilometerstand 249.648 (Tageszähler 146.5).

[Olli Z. (z80freak)]

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.

[Olli Z. (z80freak)]

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.

[Rene Z. (renezimmermann)]

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

[Olli Z. (z80freak)]

Wurdest Du denn aus dem EEPROM mit den 128km mehr schlauer bezüglich der 
Kodierung?

[Dieter (Gast)]

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.

[Rene Z. (renezimmermann)]

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

[Rene Z. (renezimmermann)]

Hi, habe nun alle bekannten Km Stände getestet:

249503
249504
249505
249510
249516
249648

Bei allen ist das Ergebnis korrekt.

[Olli Z. (z80freak)]

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.

[Dieter (Gast)]

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.

[Olli Z. (z80freak)]

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?

[Olli Z. (z80freak)]

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!

[Dieter (Gast)]

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.

[Rene Z. (renezimmermann)]

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:

0, 0, 0, 0, 0 = 0 / 5 = 0 + 2 = 2 km
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:

0, 1, 2, 3, 4 = 10 / 5 = 2 + 2 = 4 km
0x774: 0x00 0x06 0xFF 0x80 0x00 0x06 0xFF 0x01 0x00 0x06 0xFF 0x02 0x00 0x06 0xFF 0x83 0x00 0x06 0xFF 0x04

1, 2, 3, 4, 5 = 15 / 5 = 3 + 2 = 5 km
0x774: 0x00 0x06 0xFF 0x01 0x00 0x06 0xFF 0x02 0x00 0x06 0xFF 0x83 0x00 0x06 0xFF 0x04 0x00 0x06 0xFF 0x85

2, 3, 4, 5, 6 = 20 / 5 = 4 + 2 = 6 km
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

[Olli Z. (z80freak)]

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

[Rene Z. (renezimmermann)]

Morgen,

>Aber, wie kommst Du auf +2 ? In Dieters Formel steht doch +1

Ja da steht erst mal:

calc_mileage(g_ubMileage_249510) / 5 + 1

aber in der Funktion get_mileage_entry_and_check_parity() wird hier:

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?

uint8_t get_parity(uint8_t ub){
  uint8_t ubParity = 0;
  while (ub != 0){
    ubParity++;
    ub &= (ub - ubParity);
  }
  return ubParity & 0x01;
}

Bis ich dann drauf gekommen bin das sie nichts anderes als

uint8_t get_parity(uint8_t ub)                                                  
  uint8_t i = 0x80, p = 0;
  While (i){
    If (ub & i)  // check high of all bit position
      p + 1;
    i >>= 1;
  }
  Return p & 0x01;
}

macht. Allerdings ist sie effizienter.

Gruß Rene

[Dieter (Gast)]

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 .

[Olli Z. (z80freak)]

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.

[Rene Z. (renezimmermann)]

Hi,

ich hab das Programm um die zusätzliche Ausgabe und CRC Berechnung 
ergänzt.

Gruß Rene

[Olli Z. (z80freak)]

Wie könnte das denn kommen das an 0x788 einmal der Gesamt und einmal der 
Tageskilometerzählet steht?

[Rene (Gast)]

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

[Olli Z. (z80freak)]

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.

[Olli Z. (z80freak)]

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 ;-)

[Olli Z. (z80freak)]

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 (Gast)]

Wozu eigentlich das Ganze? Euch ist sicher klar das der km Stand 
mehrfach im Auto verteilt herum liegt.

[Soul E. (souleye)]

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.

[Olli Z. (z80freak)]

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.