Hilfe bei Prüfsummenberechnung eines EEPROMs

OP #7438082
Lesenswert?

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)

1
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

Angehängte Dateien:
OP #7438247
Lesenswert?

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.

Angehängte Dateien:
OP #7438263
Lesenswert?

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

OP #7447178
Lesenswert?

Ich muss nochmal fragen :-)

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

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

#7447337
Lesenswert?

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:

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

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

13
wOffset = 0x007E
14
wCrc = 0xB809
15
0000 : 0E 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
16
0010 : 00 00 00 00 00 00 00 00 00 00 00 00 09 B8         ..............
17

18
wOffset = 0x009C
19
wCrc = 0x8BBA
20
0000 : 64 00 70 00 10 27 00 00 C1 01 8B 0E 3E 04 00 00   d.p..'......>...
21
0010 : 81 23 00 00 C5 01 91 0E 3E 04 00 00 81 23 00 00   .#......>....#..
22
0020 : C0 01 8A 0E 3E 04 00 00 81 23 00 00 C3 01 90 0E   ....>....#......
23
0030 : 3E 04 00 00 81 23 00 00 C0 01 8B 0E 3E 04 00 00   >....#......>...
24
0040 : 81 23 00 00 C3 01 8F 0E 3E 04 00 00 81 23 00 00   .#......>....#..
25
0050 : C0 01 8A 0E 3E 04 00 00 81 23 00 00 C2 01 8F 0E   ....>....#......
26
0060 : 3E 04 00 00 81 23 00 00 C0 01 8A 0E 3E 04 00 00   >....#......>...
27
0070 : 81 23 00 00 C2 01 8F 0E 3E 04 00 00 81 23 00 00   .#......>....#..
28
0080 : C0 01 8A 0E 3E 04 00 00 81 23 00 00 C2 01 8F 0E   ....>....#......
29
0090 : 3E 04 00 00 81 23 00 00 C0 01 8A 0E 3E 04 00 00   >....#......>...
30
00A0 : 81 23 00 00 C2 01 8E 0E 3E 04 00 00 81 23 00 00   .#......>....#..
31
00B0 : BF 01 89 0E 3E 04 00 00 81 23 00 00 C2 01 8D 0E   ....>....#......
32
00C0 : 3E 04 00 00 81 23 00 00 BA 8B                     >....#....
33

34
wOffset = 0x0166
35
wCrc = 0xF0B8
36
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.

OP #7448866
Lesenswert?

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

#7448878
Lesenswert?

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.

Gast #7449146
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren