Forum: Mikrocontroller und Digitale Elektronik Hex-File Flashen


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von Koi (Gast)


Lesenswert?

Hallo,
wenn ich ein Hex-File flashe (80c166)) und dann komplett wieder auslese, 
ist das Ergebnis dann genauso wie die Ursprungsdatei?

von Wolfgang (Gast)


Lesenswert?

Koi schrieb:
> wenn ich ein Hex-File flashe (80c166)) und dann komplett wieder auslese,
> ist das Ergebnis dann genauso wie die Ursprungsdatei?

Nein, nicht unbedingt. Es kommt auf dein Leseprogramm und die Bedienung 
an.
Und natürlich auf den Aufbau der Ursprungsdatei.

von Georg G. (df2au)


Lesenswert?

Die Zeilenlänge ist bei Hexfiles nicht genormt. Dadurch kann es optische 
Unterschiede geben.

Der Inhalt des ausgelesenen Files ist "ein Stück von Anfang bis Ende, 
fortlaufend". Ein Hexfile darf mehrere Speicherblöcke enthalten, die 
nicht fortlaufend angeordnet sein müssen. Es dürfen auch Lücken 
vorhanden sein.

Ein Hexfile darf zusätzliche Informationen wie Kommentare oder 
Debug-Infos enthalten, die im ausgelesenen File aber fehlen werden.

von Stefan F. (Gast)


Lesenswert?

Der direkte Vergleich macht nur bei Binärdateien Sinn.

von HildeK (Gast)


Angehängte Dateien:

Lesenswert?

Koi schrieb:
> wenn ich ein Hex-File flashe (80c166)) und dann komplett wieder auslese,
> ist das Ergebnis dann genauso wie die Ursprungsdatei?

Wenn das selbe Tool das Schreiben und Lesen des µC vornimmt, ist die 
Chance durchaus groß, dass es (fast) identisch ist. Manchmal wird die 
letzte Datenzeile noch mit 0xFF aufgefüllt, was aber keine Bedeutung 
hat.
Siehe den Aufbau des Intel-HEX-Files bei z.B. 
https://de.wikipedia.org/wiki/Intel_HEX - da ist schon die Zeilenlänge 
variabel, was sich zwangsläufig auf den Zeilenanfang (RECLEN, Adresse) 
und am Ende auf die Checksumme auswirkt.

Anbei ein Ausschnitt mit farblich markierten Bereichen, nur das Schwarze 
sind die Nutzdaten. Die kannst du generell nur manuell vergleichen, wenn 
mit anderen Parametern gearbeitet wurde, z.B. mit anderer Nutzdatenlänge 
oder bei Lücken in den Adressen.
- Beige die Länge der Zeile
- blau die Speicheradresse
- braun der Datensatztyp
- schwarz die Nutzdaten
- grün die Checksumme für die Zeile

von Wolfgang (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Der direkte Vergleich macht nur bei Binärdateien Sinn.

Nein.
Viele Files im Intel-Hex Format verwenden im Wesentlichen eine 
Zeilenlänge von 0x10 Bytes und fangen auf einer 0x10-Byte Grenze an.
Beim Vergleich mit einem File-Merger sieht man dann schnell was Sache 
ist.

Nur gilt eben nicht, das geflashter und zurückgelesener File identisch 
sind.

von Wolfgang (Gast)


Lesenswert?

... und zurückgelesener File unbedingt identisch sind.

von Dieter W. (dds5)


Lesenswert?

Georg G. schrieb:
> Ein Hexfile darf zusätzliche Informationen wie Kommentare oder
> Debug-Infos enthalten, die im ausgelesenen File aber fehlen werden.

Hab ich noch nie gesehen, liegt da vielleicht eine Verwechselung mit 
einem anderen Dateiformat vor?

von Wolfgang (Gast)


Lesenswert?

Dieter W. schrieb:
> Hab ich noch nie gesehen, liegt da vielleicht eine Verwechselung mit
> einem anderen Dateiformat vor?

Dass du das noch nie gesehen hast, schließt Kommentare im Hex-File doch 
nicht aus. Bei einem Datensatz mit Daten, die geflasht werden sollen, 
muss die Zeile zwingend mit einem ":" eingeleitet werden.
Jetzt kannst du dir überlegen, was mit Zeilen ist, bei denen das nicht 
der Fall ist.
https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2012/ads264_mws228/Final%20Report/Final%20Report/Intel%20HEX%20Standard.pdf

von Georg G. (df2au)


Lesenswert?

Dieter W. schrieb:
> Hab ich noch nie gesehen, liegt da vielleicht eine Verwechselung mit
> einem anderen Dateiformat vor?

Debug Infos fingen bei Intel mit einem "$" an. Dann kamen der Name des 
Symbols und die Adresse.
Kommentare hatten als erstes Zeichen ein ";".

von Wolfgang (Gast)


Lesenswert?

Georg G. schrieb:
> Debug Infos fingen bei Intel mit einem "$" an. Dann kamen der Name des
> Symbols und die Adresse.
> Kommentare hatten als erstes Zeichen ein ";".

Hast du das schriftlich?
In der oben verlinkten Spec vom Intel Hexadecimal Object File Format ist 
dazu nichts aufgeführt.

von Georg G. (df2au)


Lesenswert?

Wolfgang schrieb:
> Hast du das schriftlich?

Nein, bzw keine Lust, danach zu suchen. Du musst es nicht glauben, 
darfst die Info gern ignorieren.
Als Tipp noch: Der ASM48 unter ISIS-2 produzierte solche Hexfiles, iirc 
der ASM86 auch.

von Wolfgang (Gast)


Lesenswert?

Georg G. schrieb:
> Nein, bzw keine Lust, danach zu suchen. Du musst es nicht glauben,
> darfst die Info gern ignorieren.

Warum, ich bin ganz deiner Meinung. Mich wundert nur, das Intel das 
nicht in der Spezifikation drin stehen hat und hätte gerne gewusst, ob 
das irgendwo in dem Zusammenhang spezifiziert ist.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Ich denke, der Begriff Hex-File ist nicht genormt. Auch Eprom-Daten 
wurden gelegentlich mal rein binär unter .bin oder .hex abgespeichert.

Nur "Intel-Hex" oder der  Motorola-S-Record" sind eindeutig. Vorteil ist 
die reine ASCII-Notierung, die auch mit einem Texteditor lesbar ist, und 
die Angaben zum Speicherort, auch mehrere Bereiche in einer Datei.

Komplizierter wird es, wenn der Mikrocontroller neben dem 
Programmspeicher noch Konfigurationsbits und EEPROM enthält. Die werden 
beim Auslesen nicht unbedingt mit abgelegt. Im Hexeditor eines 
Programmiergeräts werden sie oft als Fortführung des Adressbereichs 
zusammen mit dem Programmspeicher dargestellt.

In Eproms verwirrt auch die Adressbezeichnung, im Programmiergerät 
beginnt er mit Null, aber im Zielgerät kann er auch ganz hinten im 
Adressraum liegen. Deshalb kann man oft einen Adressversatz angeben. Das 
steht alles nicht in der Bin-Datei, man muss es sich gesondert notieren. 
Für 16-Bit-Rechner kann auch das untere und obere Byte in getrennten 
Eproms liegen, alles im Datenfile nicht erkenntlich.

von FOp (Gast)


Lesenswert?

Wolfgang schrieb:
> Jetzt kannst du dir überlegen, was mit Zeilen ist, bei denen das nicht
> der Fall ist.

Naja viele Programme werden eine solche Datei einfach als unverständlich 
zurückweisen.

Ein weiterer Punkt ist, dass in .hex-Dateien nicht für alle möglichen 
Speicherzellen ein Wert stehen muss. Es kann also Löcher in der 
Beschreibung geben. Und meist ist auch die Datei zu Ende, wenn das 
Programm zu ende ist.

Aber im Programmspeicher wird natürlich nicht markiert, ob der 
enthaltene Wert so sein muss oder nur zufällig noch von früher mal so da 
steht und eigentlich auch für die aktuelle Software völlig Mumpe ist.

von Georg G. (df2au)


Lesenswert?

FOp schrieb:
> Und meist ist auch die Datei zu Ende, wenn das Programm zu ende ist.
Für das Dateiende ist das EOF Record definiert, das optional die 
Startadresse des Programms enthalten kann.

> Datei einfach als unverständlich zurückweisen.
Das wäre unzulässig. Alle Zeilen, die nicht mit einer der definierten 
Markierungen beginnen, werden überlesen.

Das HEX-File Format ist sehr robust. Deshalb hat es sich auch so lange 
gehalten.

von Wolfgang (Gast)


Lesenswert?

Christoph db1uq K. schrieb:
> Ich denke, der Begriff Hex-File ist nicht genormt. Auch Eprom-Daten
> wurden gelegentlich mal rein binär unter .bin oder .hex abgespeichert.
>
> Nur "Intel-Hex" oder der  Motorola-S-Record" sind eindeutig. Vorteil ist
> die reine ASCII-Notierung, die auch mit einem Texteditor lesbar ist, und
> die Angaben zum Speicherort, auch mehrere Bereiche in einer Datei.

Vielleicht ist es einfach mal an der Zeit, dass sich der TO mal meldet 
und verrät, worum es bei seinen HEX-Files genau geht.

Bitte 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
Noch kein Account? Hier anmelden.