intel hex - file checksum

steht doch alles da
http://de.wikipedia.org/wiki/Intel_HEX

Die Intel-"Zeilen-Checksumme" ist bekannt.
Die Abweichungen bei den Checksummen der div. Programmer
dürfte an der Genereierung der Checksummen liegen,
die der Programmerhersteller gewählt hat. Die sind
leider nicht mal von der Byteanzahl her gleich.
Ich würde versuchen vom Hersteller des Programmers
näheres zu erfahren, vielleicht hast du Glück und
erfährst wie es gemacht wird.
Wenn erlaubt, stell es dann doch auch hier ins Forum.

Wenn es um externes Programmieren geht:
Laß ein Muster programmieren, teste es aus, und
gib es dann frei. Behalte das Muster als Beleg.
(Beim Muster sollte man auf die Auslesesperre verzichten)
Achtung die Flags können, müssen aber nicht in der
Checksumme enthalten sein.

Besten Dank erst einmal.
@Peter:
Ja, da steht der Aufbau, aber INNERHALB des hex-files.
Es gibt aber eine komplette file-checksum.
Da suche ich den Algorithmus.

Alter Hase:
Ja- so haben wir den Ablauf auch immer eingehalten.
Nur gibt es noch Optionsbytes, die scheinbar mit
einbezogen sind, oder nicht.
Da wollte ich das nachvollziehen, wie das gemacht wurde.

Es geht übrigens um einen St62-Controller von STM.

>Es gibt aber eine komplette file-checksum.

Das INTEL-Hex-Format spezifiziert keine Checksumme für die gesamte 
Datei.
Es muss sich also um eine Variante dieses Formats handeln.

Ja, das ist das Problem.
Deshalb meine Frage, ob es einen Tipp
für mich gibt.

Qwertz schrieb:
>>Es gibt aber eine komplette file-checksum.
>
> Das INTEL-Hex-Format spezifiziert keine Checksumme für die gesamte
> Datei.
> Es muss sich also um eine Variante dieses Formats handeln.

Hallo,

wenn das so ist, könnte man ja die (wahrscheinlich vorletzte oder 
letzte) Zeile mit dieser Checksum streichen und hätte ein normales 
Intel-Hex-File, das sollte eigentlich jeder Programmer können. Ist es 
umgekehrt und der Programmer verlangt einen solchen Eintrag, müsste man 
natürlich Format und Berechnung kennen.

Programmer-Checksum: die meisten Programmer (ich hatte schon eine ganze 
Menge im Lauf der Jahre) addieren alle Bytes des Proms (nicht des 
Hexfiles!) und zeigen die Summe modulo 16 bit als 4stellige Hexzahl an. 
Überprüft wird das nicht, dient nur zur Kontrolle durch den Benutzer. 
Ausserdem ist es nicht genormt und somit auch nicht garantiert.

Gruss Reinhard

PS es ist verbreitete und vernünftige Praxis, diese 4stellige Hexzahl 
neben der Bezeichnung auf dem Prom zu vermerken und auch mit den 
Unterlagen zu speichern. Man kann noch weiter gehen und die korrekte 
Summe beim Start des Systems prüfen, oder alle Eproms so ergänzen, dass 
sie die Prüfsumme 0 haben (wie im PC).

>Ja, das ist das Problem.
>Deshalb meine Frage, ob es einen Tipp
>für mich gibt.

>Es geht übrigens um einen St62-Controller von STM.

Wir würden ja gerne einen Tip geben. Aber die Angabe ST62 von STM reicht 
offenbar nicht aus. Schreib uns doch bitte, welche Programmierumgebung 
Du benutzt. Compiler, IDE, Programmer etcpp. Alles was hilfreich sein 
kann.

Olala- Ihr wollt aber alles ganz genau wissen ; )
Ist aber auch kein Geheimnis.
Konkret ist es ein ST62T20C.
Programmiert wird in Assembler (AST6).
Die WINEE-Software von STM gibt eine 5-byte Checksumme aus.
Unser LLOYD-Research-Programmer aber 4byte.
Da ist immer in den beiden LSBs ein Unterschied.

Das wollte ich einfach entschlüsseln.
Ich habe jetzt einmal ein "Mini-Programm" erstellt:
hex-file
:050800000DD8FE4D04BF
:100FF000044D4980044D044D04040404044D09804B
:00000001FF
WINEE gibt als Checksumme 4DA heraus.
Auf den LLOYD habe ich gerade keinen Zugriff-
der ist in der Fertigung.

Wir haben auch die Checksumme als Vorgabe in den
Fertigungsunterlagen.
Nur dieser Unterschied "wurmt" uns.