Moin zusammen, eine Frage zur Generierung von Checksummen für ganze files. Wie man innerhalb (am Ende der Zeile) die Checksumme im hex-file bildet, kann man ja ergogglen. Wie sieht das aber mit der file-Checksumme aus, die, z.B. ein Programmer erstellt? Gibt es da allgemein übliche Verfahren? Hintergrund ist, das ich Abweichungen bei verschiedenen Programmern habe. Ein paar Stichworte wären herzallerliebst. Gruss Dietmar
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.
Manche Steuersoftware für Programmiergeräte füllt die unbenutzten Speicherbereiche mit 00, andere mit FF. Daraus ergibt sich zwangsweise schon ein Unterschied in der Prüfsumme. Die mögliche Einbeziehung von Konfigurationsdaten in die Prüfsumme kann ebenfalls zur Problematik beitragen. Ich habe mal das Hexfile geladen und bekomme als Prüfsumme 000FDFEF wenn die nicht benutzten Bereiche FF enthalten. 00004DA bekomme ich, wenn vor dem Laden der Datei der Puffer mit 00 gefüllt wird.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.