Hilfe bei Prüfsummenberechnung eines EEPROMs

[Christian S. (chris02)]

Hallo zusammen,

für eine Reparatur muss ich den Inhalt eines EEPROMs (64kB SPI EEPROM, 
M95640) verändern. Das Problem ist eine Prüfsumme für Datenblöcke, 
welche ich nicht selber berechnen kann. Das EEPROM hängt an einem C2000 
von TI (TMS320F28335PGFA)

In dem EEPROM sind mehrere dieser Blöcke, mit der Größe von 160 Byte. 
Diese Blöcke möchte ich modifizieren können. Die Blöcke, kann ich, wenn 
ich sie aus einem anderem EEPROM rauskopiere, einzeln austauschen. Somit 
scheint es keine Checksum für das gesamte EEPROM zu geben. Der Block 
beginnt immer mit "50 00 40 00". Und am Ende des Blocks sind die letzten 
16 Bit anscheinend die Checksum. Soweit meine Ananlyse. Ob diese aber 
korrekt sind, weiß ich nicht.

Recht weit am Ende des Bins gibt es auch leere Blöcke, mit denen habe 
ich versucht habe die Checksum zu berechnen. (Bsp. 0x14C0-155F)

50 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 42

Auch hier sieht man wieder den Anfang mit 50 00 40 00 und die letzten 16 
Bit als vermeintliche Checksum "58 42".
Verschiedene Möglichkeiten habe ich probiert. Die Checksum mit und Ohne 
"50 00 40 00" zu berechnen, auf Basis verschiedener CRC16 Möglichkeiten, 
die es in Online Kalkulatoren gibt.

Ändere ich Werte in diesem Block, ohne die Checksum anzupassen, startet 
der µC nicht.

Im Anhang ist ein EEPROM Dump. Gerne kann ich, falls notwenidg, noch 
weitere zur Verfügung stellen.
Sonst hoffe ich, dass alles soweit verständlich ist.

Habt ihr eine Idee, wie die Checksum berechnet wird? Braucht ihr sonst 
noch Infos?

Vielen Dank und viele Grüße
Chris

[Dergute W. (derguteweka)]

Moin,

reveng meint, das waere wohl so ein CRC:

width=16  poly=0x1021  init=0xffff  refin=true  refout=true  xorout=0x0000  check=0x6f91  residue=0x0000  name="CRC-16/MCRF4XX"

Gruss
WK

[Christian S. (chris02)]

Danke dir, passt :)

Vielleicht kannst du mir auch noch helfen, das nun in den HexEditor ein 
zu binden.

Der HxD bringt ja schon die Möglichkeit für CRCs mit. Dort lassen auch 
auch custom CRCs einbinden.
Nun habe ich von https://reveng.sourceforge.io/crc-catalogue/16.htm bei 
CRC-16/MCRF4XX die Daten genommen und in den HxD eingepflegt (linkes 
Fenster). Im rechten Fenster die Breiten und Little/Big Endian habe ich 
verändert, komme aber auch nicht auf das, was ich erwarte.

Es kommen immer andere Prüfsummen raus.

[Dergute W. (derguteweka)]

Moin,

Christian S. schrieb:
> Im rechten Fenster die Breiten

Die Breite der Summanden bzw. Bitbreite wuerd' ich auf 8 lassen; aber 
von HxD hab' ich keine Ahnung.

Gruss
WK

[Christian S. (chris02)]

Habe ich alles schon probiert. Hast du ne andere Idee? Wäre so halt 
nett, dass ich im HexEdit gleich editiren kann und die passende CRC raus 
bekomme.
Darf auch gerne ein anderer Editor sein.

[Dergute W. (derguteweka)]

Moin,

Neee, da muss ich leider passen. Haste auf deinem Rechner reveng am 
laufen und liefert das dann wenigstens passende Werte?
Aber komfortabel waere schon anders ;-)

Gruss
WK

[Christian S. (chris02)]

Nutze https://crccalc.com/, da kommen auch die passende Ergebnisse raus. 
Und dort stehen auch die gleichen Parameter, wie auf reveng. Daher wird 
das schon passen :-)
Aber ich bin schonmal arbeitsfähig, das ist gut. Nun kann ich noch ein 
wenig an der Eleganz feilen. Vorher musste ich immernoch das alte EEPROM 
auslesen und die Daten kopieren. Da dies aber in Conformal Coating 
getaucht ist, ist das ein Krampf...


Gruß
Chris

[Christian S. (chris02)]

Ich muss nochmal fragen :-)

Und zwar in diesem Bereich ist ebenfalls ein CRC Check eingebaut:

53 00 4D 00 41 00 49 00 44 00 00 00 82 02 01 A7 26 00 31 00 53 00 54 00 50 00 42 00 46 00 53 00 42 00 47 00 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 08 00 00 00 00 00 00 00 03 00 15 00 02 00 50 00 55 00 01 00 01 00 00 00 00 00 50 8C 0E 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 B8 64 00 70 00 10 27 00 00 89 01 64 0E BB 03 00 00 EB 22 00 00 8B 01 69 0E BB 03 00 00 EB 22 00 00 88 01 64 0E BB 03 00 00 EB 22 00 00 8A 01 69 0E BB 03 00 00 EB 22 00 00 88 01 64 0E BB 03 00 00 EB 22 00 00 8A 01 68 0E BB 03 00 00 EB 22 00 00 88 01 64 0E BB 03 00 00 EB 22 00 00 89 01 68 0E BB 03 00 00 EB 22 00 00 88 01 64 0E BB 03 00 00 EB 22 00 00 89 01 68 0E BB 03 00 00 EB 22 00 00 88 01 63 0E BB 03 00 00 EB 22 00 00 8A 01 68 0E BB 03 00 00 EB 22 00 00 87 01 63 0E BB 03 00 00 EB 22 00 00 89 01 67 0E BB 03 00 00 EB 22 00 00 86 01 62 0E BB 03 00 00 EB 22 00 00 89 01 66 0E BB 03 00 00 EB 22 00 00 C4 8D 00 00 B8 F0

Ich vermute, dass C4 8D hier die CRC ist. Die zwei Byte davor sind 
wahrscheinlich eine Art Trennzeichen zu dem nächsten Bereich im EEPROM.

Danke :-)

[Dieter S. (ds1)]

Schau Dir die Struktur von M95640_SOIC8.BIN an.

Die Daten ab Offset 0x0020..0x0169 wiederholen sich ab Offset 0x016A.

Innerhalb des Bereichs 0x0020..0x0169 gibt es wohl die folgenden fünf 
Bereiche die mit der CRC16 gesichert sind:

wOffset = 0x0020
wCrc = 0xA701
0000 : 53 00 4D 00 41 00 49 00 44 00 00 00 82 02 01 A7   S.M.A.I.D.......

wOffset = 0x0030
wCrc = 0x8B16
0000 : 26 00 31 00 53 00 54 00 50 00 42 00 46 00 53 00   &.1.S.T.P.B.F.S.
0010 : 42 00 47 00 34 00 00 00 00 00 00 00 00 00 00 00   B.G.4...........
0020 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030 : 02 00 08 00 00 00 00 00 00 00 03 00 14 00 60 00   ..............`.
0040 : 51 00 10 00 10 00 01 00 00 00 00 00 16 8B         Q.............

wOffset = 0x007E
wCrc = 0xB809
0000 : 0E 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0010 : 00 00 00 00 00 00 00 00 00 00 00 00 09 B8         ..............

wOffset = 0x009C
wCrc = 0x8BBA
0000 : 64 00 70 00 10 27 00 00 C1 01 8B 0E 3E 04 00 00   d.p..'......>...
0010 : 81 23 00 00 C5 01 91 0E 3E 04 00 00 81 23 00 00   .#......>....#..
0020 : C0 01 8A 0E 3E 04 00 00 81 23 00 00 C3 01 90 0E   ....>....#......
0030 : 3E 04 00 00 81 23 00 00 C0 01 8B 0E 3E 04 00 00   >....#......>...
0040 : 81 23 00 00 C3 01 8F 0E 3E 04 00 00 81 23 00 00   .#......>....#..
0050 : C0 01 8A 0E 3E 04 00 00 81 23 00 00 C2 01 8F 0E   ....>....#......
0060 : 3E 04 00 00 81 23 00 00 C0 01 8A 0E 3E 04 00 00   >....#......>...
0070 : 81 23 00 00 C2 01 8F 0E 3E 04 00 00 81 23 00 00   .#......>....#..
0080 : C0 01 8A 0E 3E 04 00 00 81 23 00 00 C2 01 8F 0E   ....>....#......
0090 : 3E 04 00 00 81 23 00 00 C0 01 8A 0E 3E 04 00 00   >....#......>...
00A0 : 81 23 00 00 C2 01 8E 0E 3E 04 00 00 81 23 00 00   .#......>....#..
00B0 : BF 01 89 0E 3E 04 00 00 81 23 00 00 C2 01 8D 0E   ....>....#......
00C0 : 3E 04 00 00 81 23 00 00 BA 8B                     >....#....

wOffset = 0x0166
wCrc = 0xF0B8
0000 : 00 00 B8 F0                                       ....

Ab Offset 0x02C0 kommen weitere mit der CRC16 gesicherte Blöcke, die 
Länge des gesamten Block in 16-Bit Einheiten steht jeweils am Anfang des 
Block (also diese Länge "mal 2" um die Länge des Blocks in Bytes zu 
bekommen).

Bei den obigen Blöcken steht wohl teilweise ebenfalls eine Länge am 
Anfang, allerdings ist es dann die Länge in 16-Bit Einheiten ohne die 
CRC16.

[Christian S. (chris02)]

Hallo Dieter,
vielen Dank für die ausführliche Auflistung. Das sich der Block ab der 
Adresse 0x169A widerholt ist mir auch aufgefallen, daher auch der Auszug 
oben.

Aber auf diese granulare Gliederung, wie du sie oben beschrieben hast, 
bin ich nicht gekommen. Kann es aber nachvollziehen.
Magst du mir noch verraten, wie du darauf gekommen bist? Durch scharfes 
hinsehen und Erfahrung oder wie bist du daran gegangen?

Viele Grüße
Chris

[Dieter S. (ds1)]

Christian S. schrieb:
>
> Magst du mir noch verraten, wie du darauf gekommen bist? Durch scharfes
> hinsehen und Erfahrung oder wie bist du daran gegangen?

Ich habe zwar eine gewisse Struktur innerhalb des Blocks 0x0020..0x0169 
gesehen aber für die mit CRC16 gesicherten Bereiche reicht einfaches 
Durchprobieren: Man schaut ob die CRC16 für alle möglichen Bereiche 
stimmt, das sind ein paar Zeilen Code und ist in wenigen Sekunden 
durchprobiert. Von den so erhaltenen Blöcken läßt man die weg, die nicht 
sinnvoll erscheinen, übrig bleiben die weiter oben beschriebenen. Die 
liegen hintereinander ohne Lücke, und das Ganze sieht einigermaßen 
sinnvoll aus.

[Christian S. (chris02)]

Verstehe :-) Für mich (rudimentäre C Grundlagen) ist das mehr als ein 
paar Zeilen Code. Aber ich hab wieder viel dazu gelernt :-)

Was mir (auch schon bei anderen EEPROMs) aufgefallen ist, dass bestimmte 
Sachen immer doppel geschrieben werden. Wie auch hier.

Welche Bewandtnis hat das?

[Ge L. (Gast)]

Christian S. schrieb:

> Was mir (auch schon bei anderen EEPROMs) aufgefallen ist, dass bestimmte
> Sachen immer doppel geschrieben werden. Wie auch hier.
>
> Welche Bewandtnis hat das?

EEPROMs haben eine begrenzte Lebensdauer, und die sinkt auch noch mit 
der Anzahl der Schreibvorgänge. Nach typisch 20 Jahren sind die Daten 
weg. Die Lebensdauer ist normalverteilt. Du hast also welche, die 40 
Jahre halten, und andere sind nach 5 Jahren schon hin.

Damit das nicht gleich ein Garantiefall wird, legt man die Daten 
mehrfach ab und nutzt dann halt einen anderen Block. Welcher kaputt ist 
merkt man ja an der CRC.