STM32F030C8T6: HEX-File auslesen

[Martin M. (gga)]

Hallo,

ich habe einen STM32F030C8T6, aus dem ich das HEX-File auslesen möchte. 
Ich habe mehrere Möglichkeiten hierfür:

1) Segger J-Trace mit Segger embedded Studio
2) ST-Link/V2 mit STM32 ST-LINK Utility
3) ST-Link/V3 mit STM32CubeProgrammer

Zum Testen habe ich ein mir bekanntes HEX-File verwendet und 
anschließend versucht, es auszulesen. Wenn man die Dateien jedoch mit 
Winmerge vergleicht, dann findet man über einen großen Bereich viele 
Unterschiede (siehe Anhang). Die ausgelesene Datei wurde mit Segger 
ausgelesen. Auslesen mit Variante 2 und 3 geht auch nicht besser.

Was muß ich machen, daß ich ein file auslese, das mit dem programmierten 
zu 100% übereinstimmt?

PS:
Der STM32 ist nicht gegen Auslesen geschützt.
Ich möchte mit der Platine was Testen und muß anschließend das alte 
HEX-File zurück spielen. Es ist nicht bekannt, welche Variante 
ursprünglich drauf gespielt wurde.

Gruß
Martin

[W.S. (Gast)]

Martin M. schrieb:
> Was muß ich machen, daß ich ein file auslese, das mit dem programmierten
> zu 100% übereinstimmt?

Es in ein Binärfile konvertieren und das Ausgelesene aus deinem µC 
ebenfalls als Binärfile speichern.

Ansonsten lies einfach mal nach, wie Hexfiles aufgebaut sind.

W.S.

[Georg (Gast)]

Martin M. schrieb:
> Was muß ich machen, daß ich ein file auslese, das mit dem programmierten
> zu 100% übereinstimmt?

Soweit ich auf den ersten Blick sehen kann, unterscheiden sich die 
Inhalte garnicht, es wird nur eine andere Record-Einteilung benutzt. Man 
darf Hexfiles nicht als Text vergleichen, massgebend ist NUR der binäre 
Inhalt.

Georg

[Uff Basse (Gast)]

Martin M. schrieb:
> ich habe einen STM32F030C8T6, aus dem ich das HEX-File auslesen möchte.

Es gibt in einem Controller kein Hex-File, es sei denn er betreibt
in seinem Speicher ein eigenes Dateisystem. Bei dir eher
unwarscheinlich ....

Daher kannst du auch kein Hex-File auslesen.

Was du auslesen kannst ist der binäre Speicherinhalt des
Controllers, und dieser wird dann ggf. in ein ein Hex-File
geschrieben das dem Inhalt des Speichers entpricht.

Zum korrekten Auslesen gehört dass man Anfangsandresse und
Speichergrösse des Controllers kennt, diese sollte man
dem lesenden Programm mitteilen. Dann kann eigentlich nicht
mehr soviel schiefgehen.

[Bernd K. (prof7bit)]

Deshalb benutze ich wo es geht keine hex-files mehr, eher erzeuge und 
flashe ich bin files (gerne auch mehrere nacheinander), die kann man 
sich auch bequem mit dem Hex-Editor anschauen und vergleichen und das 
strengt die Augen nicht so an wie dieses menschenunlesbare 
Intel-Hex-Format.

[Johannes S. (Gast)]

Wenn man die gcc benutzt, dann kann man mit objcopy die hex in bin 
konvertieren. Aber die o.g. Tools können sicher auch gleich bin 
speichern.

arm-none-eabi-objcopy ausgelesene_Datei__Intel_Hex_.hex a.bin -O binary -I ihex

arm-none-eabi-objcopy programmierte_Daten__Intel_Hex_.hex  p.bin -O binary -I ihex

zeigt das die Inhalte gleich sind. Die Programmierte wird nur am Ende 
mit Nullen gefüllt, die Ausgelesene hat unprogrammierten Flash mit 0xff.

[Nop (Gast)]

Bernd K. schrieb:
> Deshalb benutze ich wo es geht keine hex-files mehr

Hexfiles haben den großen Vorteil, daß die Adreß-Informationen in der 
Datei selber stecken, während man sie bei Binfiles separat mitführen 
muß.

Außerdem kann man bei Bedarf aus einem Hexfile leicht ein Binfile zum 
Anschauen erzeugen, umgedreht geht das nicht ohne Zusatzinformation.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Auch in gdb kann man ein HEX file erzeugen. Im gdb "help dump" eingeben 
und die Hinweise verfolgen.

[Martin M. (gga)]

Beim Segger kann man auswählen, ob er HEX oder BIN erzeugen soll. Habe 
nun auf BIN gestellt.

Ich habe es mit einer BIN-Datei hin gebracht, die 64.968 Bytes hat. Ich 
mußte allerdings Size im Cube-Programmer auf 0xFDC8 stellen (siehe 
Anhang), damit die Dateien zu 100% identisch sind.

Nun habe ich eine andere BIN-Datei drauf gespielt, die 3.726 Bytes hat. 
Wenn ich hier Size auf 0xFDC8 lasse, ist die ausgelesene Datei 
entsprechend zu groß (64.968 Bytes). Nun weiß man ja aber zuvor nicht 
immer, wie groß die auszulesende Datei ist. Was stellt man dann ein? 
Generell 0xFFFF? Ist das dann ein Problem, wenn man die zu große Datei 
zurück flasht? Da das Programm auf die unbenutzten Bereiche 
normalerweise erst gar nicht kommt, sollte ides keine Rolle spielen, 
oder?

[Johannes S. (Gast)]

das Tool kann nicht wissen wie groß das Programm ist, daher muss man 
alles auslesen. Man könnte vom Dateiende an die 0xff verfolgen und den 
Rest abschneiden.
Wenn man vor dem Flash schreiben nicht löscht kann aber auch alter Müll 
hinter dem neuen Programm stehen.
Und eine Programm kann auch selber Blöcke im Flash schreiben, macht man 
z.B. um fehlendes EEPROM zu emulieren. Dann hilft auch nur den Speicher 
komplett zu sichern.

[Pete K. (pete77)]

Man könnte auch einen MD5 Hash für beide Dateien berechnen und dann auf 
Gleichheit prüfen.

[Stefan F. (Gast)]

Martin M. schrieb:
> Was stellt man dann ein?

Im Zweifelsfall liest man den ganzen Speicher aus. Wie viel davon 
tatsächlich benutzt wurde ist dann egal.

> Ist das dann ein Problem, wenn man die zu große Datei zurück flasht?

Nein.

[Bernd K. (prof7bit)]

Nop schrieb:
> Hexfiles haben den großen Vorteil, daß die Adreß-Informationen in der
> Datei selber stecken, während man sie bei Binfiles separat mitführen
> muß.

Das ist wohl wahr, aber da ich zumindest bei mir ohnehin nur 
scriptgesteuert flashen lasse und ich das jeweils zugehörige 
Flash-Script welches ohnehin erforderlich ist weil es auch noch andere 
Sachen macht wie Lockbits setzen etc.  sowieso immer zusammen mit den 
Firmware-Files ausliefern muss (auch wenn sie hex wären) ist das kein 
zusätzliches Problem.

Das Flash-Script oder Flash-Tool das zu einer Firmware oder einem 
Produkt gehört fange ich immer schon gleich in der Anfangsphase an weil 
ich es auch während der Entwicklung der Firmware brauche (weil es oft 
mehr können muss als nur flashen) und das wird dann nebenher mitgepflegt 
und ist im selben Repository, so ist immer alles zusammen was untrennbar 
zusammengehört und es kann nichts mehr versehentlich schiefgehen oder 
vergessen werden, selbst Montags nicht.