Problem,ATmeg1284p brennen auslesen und erneut das neue hex-File in einen andern ATmega1284p brennen

[Bernhard S. (bernhard)]

Geschätztes Forum,

vor Jahren schrieb ich ein Assember-Programm, brannte es in ATmega1284p.

Nun wollte ich das Programm aus dem ATmega auslesen und

in eine anderen ATmega1284p brennen.

Beim Brennvorgang plötzlich eine Fehlermeldung:

"Original- und gelesene Daten haben unterschiedliche Längen."

Mit Excel konnte ich die originalgebrannte- und ausgelesene Datei 
problemlos miteinander vergleichen und tatsächlich Unterschiede 
feststellen.

Warum ist das so, was mache ich falsch, geht das überhaupt?

Danke

Bernhard

[Wolfgang (Gast)]

Bernhard S. schrieb:
> Warum ist das so, was mache ich falsch, geht das überhaupt?

Welche deiner vier Hex-Dateien ist was?
Welche Dateien haben angeblich unterschiedliche Längen?

[Helmut -. (dc3yc)]

Dann brenne doch mal dein ausgelesenes Programm in den neuen ATmega, 
lese das neu gebrannte aus und vergleiche die beiden ausgelesenen Files. 
Wenn alles passt, sollten die gleich sein. Weil die Original-Hex-Dateien 
müssen nicht mit den ausgelesenen übereinstimmen. Siehe, was Tante 
Gockel über das Hex-Format weiss.

[c-hater (Gast)]

Bernhard S. schrieb:

> Nun wollte ich das Programm aus dem ATmega auslesen und
>
> in eine anderen ATmega1284p brennen.
>
> Beim Brennvorgang plötzlich eine Fehlermeldung:
>
> "Original- und gelesene Daten haben unterschiedliche Längen."

Das dürfte eine ziemlich schwachsinnige Fehlermeldung sein. Deine eigene 
Auswertung zeigt ja, dass die unterschiedliche Länge höchstens ein 
sekundäres Problem sein kann. Das Problem ist: Was auch immer in der 
Quelldatei stand, ist offensichtlich nicht korrekt in des Target 
geschrieben worden. Da stimmt ja praktisch nix.

> Mit Excel konnte ich die originalgebrannte- und ausgelesene Datei
> problemlos miteinander vergleichen und tatsächlich Unterschiede
> feststellen.
>
> Warum ist das so, was mache ich falsch, geht das überhaupt?

Entweder hast du irgendwann mal irgendwelche Lockbits im Target 
aktiviert oder irgendwas mit der Programmierhardware bzw. der 
Verkabelung stimmt nicht.

[Thomas Z. (usbman)]

Hexdateien zu vergleichen macht nur begrenzt Sinn. Das funktioniert nur 
wenn die RecLen in beiden Fällen gleich ist.
Wandle deine Hex Dateien in Binär Files um und mach einen 
Binärvergleich. Entweder mit einem Tool oder im einfachsten Fall mit fc

[Wolfgang (Gast)]

Thomas Z. schrieb:
> Hexdateien zu vergleichen macht nur begrenzt Sinn. Das funktioniert nur
> wenn die RecLen in beiden Fällen gleich ist.

Unsinn. Solange Recordlänge und Recordadresse gleich sind, wie es hier 
der Fall ist, ist der Vergleich überhaupt kein Problem.

[michael_ (Gast)]

Denke ich auch.
Für den Vergleich gibt es Hex-Editoren.

c-hater schrieb:
> Entweder hast du irgendwann mal irgendwelche Lockbits im Target
> aktiviert

Die sind nicht im Flash-File.

[michael_ (Gast)]

michael_ schrieb:
> Denke ich auch.

Bezog sich hierauf.

Thomas Z. schrieb:
> Hexdateien zu vergleichen macht nur begrenzt Sinn. Das funktioniert nur
> wenn die RecLen in beiden Fällen gleich ist.
> Wandle deine Hex Dateien in Binär Files um und mach einen
> Binärvergleich. Entweder mit einem Tool oder im einfachsten Fall mit fc

[Malu (Gast)]

michael_ schrieb:
> Die sind nicht im Flash-File.

Aber wenn sie gesetzt sind, werden nicht die richtigen Daten 
ausgelesen...

[michael_ (Gast)]

Zeig mal!

Sicher das Datenveränderungs-Lockbit.

[Thomas Z. (usbman)]

Wolfgang schrieb:
>> Hexdateien zu vergleichen macht nur begrenzt Sinn. Das funktioniert nur
>> wenn die RecLen in beiden Fällen gleich ist.
>
> Unsinn. Solange Recordlänge und Recordadresse gleich sind
nichts andere hatte ich geschrieben.

Man kann schon in der ersten Zeile sehen, dass irgendwas nicht mit 
Checksummenbyte stimmt. Entweder beim Lesen oder beim Schreiben wird 
Mist gebaut.
Ich hab jetzt nicht geprüft welche Variante die Richtige ist.
1Aread und 1Awrite sind übrigens abgesehen von der 1. und letzten Zeile 
identisch.
2A und 2B komplett unterschiedliche Programme

[Malu (Gast)]

michael_ schrieb:
> Zeig mal!
>
> Sicher das Datenveränderungs-Lockbit.

Wusstest du nicht, dass beim Auslesen mit gesetztem Lockbit bei einigen 
µC nur FF zurückgelesen wird, bei anderen Zufallswerte? Welcher was 
macht, hab ich gerade nicht im Kopf, aber die Tatsache an sich kenne 
ich. Du scheinbar nicht, deshalb deine Häme...

[Wolfgang (Gast)]

Thomas Z. schrieb:
> nichts andere hatte ich geschrieben.

Und was soll dein Beitrag dann für diesen Thread bringen?

[Stefan F. (Gast)]

Bei beiden "Programmen" hat "Datei Read" den selben Inhalt.

Also wurde wohl der als "Datei Write" beschriftete Kram doch nicht 
geschrieben.

[Thomas Z. (usbman)]

die 2 Datein haben nix gemeinsam

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Bei beiden "Programmen" hat "Datei Read" den selben Inhalt.
>
> Also wurde wohl der als "Datei Write" beschriftete Kram doch nicht
> geschrieben.

Bist du stoned? Wen der Vergleich zwischen Schreiben und Lesen keine 
Überinstimmung hat, weiß man nur dass entweder das Schreiben oder 
das Lesen (oder gar beides) falsch lief. Man kann aber NICHT 
unterscheiden was davon. Und schon garnicht kann man ermitteln warum...

Das alles ginge nur mit weiteren Hintergrundinformationen seitens des 
TO. Er müsste z.B. explizit bezeugen, dass er zwischen Schreiben und 
Lesen kein Lockbit gesetzt hat und dass er vor dem Schreiben ein 
Chip-Erase durchgeführt hat. Dann könnte man das erstmal eleminieren.

Dann müsste er erklären, ob er des Schreiben mit einem Verify 
durchgeführt hat, und ob dieses Erfolg gemeldet hat. Falls ja, hätte er 
dann allerdings Probleme, zu erklären, wie er zu dem gelesenen File 
kam...

[Bernhard S. (bernhard)]

Danke für Eure vielen Tipps und Anregungen.

Helmut -. schrieb:
> Dann brenne doch mal dein ausgelesenes Programm in den neuen ATmega.

Gleiche Fehlermeldung, geht also auch nicht.

Aber ich konnte einen anderen ATmega1284p mit einem sehr umfangreichen 
Programm auslesen und die ausgelesene Datei problemlos wieder in andere 
ATmega's brennen.

Demnach könnte mit der ausgelesenen Datei aus meinem Orginalgerät etwas 
nicht stimmen.

Die Fuses sind bei allen ATmega's gleich.

Anfangs dachte ich, dass eventuell die Hardware um den ATmega störend 
beim Auslesen einwirkt.... Fehlanzeige.

Mehrfach aus dem Originalgerät ausgelesen... alle ausgelesenen Dateien 
sind gleich.

Noch ein seltsames Phänomen:

Ein funktionierendes Webserver hex-File in einen anderen ATmega 
gebrannt, dann wieder ausgelesen, und das ausgelesene hex-File wieder 
gebrannt... Fehlermeldung :(

Ich lege mal das Original und das ausgelesene hex-File mit dazu.

Und einen Vergleich beider Dateien als Excel-Datei, in 2 Zeilen 
unterscheiden sich beide Dateien.

Frage: Warum kann das ausgelesene hex-File nicht wieder gebrannt 
werden?



c-hater schrieb:
> Dann müsste er erklären, ob er des Schreiben mit einem Verify
> durchgeführt hat, und ob dieses Erfolg gemeldet hat. Falls ja, hätte er
> dann allerdings Probleme, zu erklären, wie er zu dem gelesenen File
> kam..

Ich denke schon, verwendet wurde ein
"mySmartUSB ligt" und "myAVR ProgTool V1.39"

[Bernhard S. (bernhard)]

Grundproblem:

Zwei nahezu gleichaufgebaute WEB-Server zeigen folgendes:

Webserver-1, mit einer älteren Softwareversion, ich weiß nicht genau 
welche, meldet sich problemlos beim Router an.

Webserver-2, seit Jahren in Betrieb, meldet sich, nach einem 
Softwareupdate, nicht korrekt beim Router an, obwohl er per Ping 
angesprochen und auch im Heimnetzwerk ausgelesen werden kann.

MAC und IP-Adressänderung hift nicht.

Wenn er im Router nicht erkannt wird ist eine Portumleitung nicht 
möglich, also von außen nicht erreichbar.

Nun wollte ich das funktionierende Progamm vom Webserver-1 auf den 
Webserver-2 übertragen, um Hardwareprobleme auszuschließen.

Leider ohne Erfolg.

[michael_ (Gast)]

Da muß man runter auf die unterste Ebene und Kreuzvergleiche machen.
Anderen MC, andere Soft, anderen Programmer usw.

Evtl. hat der PC einen RAM-Fehler.

Malu schrieb:
> Wusstest du nicht, dass beim Auslesen mit gesetztem Lockbit bei einigen
> µC nur FF zurückgelesen wird, bei anderen Zufallswerte? Welcher was
> macht, hab ich gerade nicht im Kopf, aber die Tatsache an sich kenne
> ich. Du scheinbar nicht, deshalb deine Häme...

Ach, habe genug damit zu tun gehabt.
Der TO hat den MC nicht gegen Auslesen geschützt.
Das sehe anders aus. Du solltest deinen Kopf wieder mit Wissen füllen.

[Bernhard S. (bernhard)]

michael_ schrieb:
> Da muß man runter auf die unterste Ebene und Kreuzvergleiche machen.
> Anderen MC, andere Soft, anderen Programmer usw.

sorry, nicht hilfreich :(

[michael_ (Gast)]

Bernhard S. schrieb:
> mySmartUSB ligt

Der sollte doch auch unter Studio laufen.
Also testen.

https://shop.myavr.com/index.php?sp=article.sp.php&artID=200006

[michael_ (Gast)]

Bernhard S. schrieb:
> michael_ schrieb:
>> Da muß man runter auf die unterste Ebene und Kreuzvergleiche machen.
>> Anderen MC, andere Soft, anderen Programmer usw.
>
> sorry, nicht hilfreich :(

Dann lass es eben.

Du wirst wohl deine Hardware testen können.
Einen anderen Prozessor mit irgendeinen Programm zu füttern.
Wie oben schon genannt, mit Studio oder einem anderen Brennprogramm zu 
testen.
Und, und und...
Da muß man eben mal hinten die Backen zusammenkneifen und durch!

Ist das zu viel verlangt?

[Stefan F. (Gast)]

c-hater schrieb:
> Bist du stoned?

Nein bin ich nicht. Ich sehe, dass er zwei mal den Code von Programm A 
gelesen hat. Also hat er das Programm B nicht geschrieben, warum auch 
immer. Vielleicht hat er die Dateien verwechselt oder vergessen auf 
"Start" zu klicken. Irgendwas triviales dieser Art.

[Thomas Z. (usbman)]

Bernhard deine 2 Hexfiles sind prinzipiell gleich.
Lediglich der Start Record enthält eine falsche Prüfsumme da müsste beim 
Auslesen auch FC stehen (da 2 mal 0x02) das ist ein Bug in deiner 
Auslesesoftware.
Am Schluss ist es einfach so dass deine Auslesesoftware 1 Byte weniger 
liest, weshalb diese Zeile unterschiedlich ist.
Ich würde mir deine Flashsoftware näher anschauen da stimmt 
offensichtlich was nicht.
Zusammengefasst: deine ausgelesene Software ist 1 Byte kleiner was 
verwunderlich ist da doch immer 16Bit gelesen werden sollten

[HildeK (Gast)]

Thomas Z. schrieb:
> Zusammengefasst: deine ausgelesene Software ist 1 Byte größer. In diesem
> letzten Byte steht 0xFF.

Meine SW (AVR-Studio) z.B. liest immer das gesamte Flash aus. Da das 
Flash meist nicht bis zum Anschlag voll ist, wird der ausgelesene File 
eben größer und mit 0xFF gefüllt - was ja auch im Flash drin steht. 
Damit sind Original- und gelesener File nicht mehr identisch, schon 
wegen unterschiedlicher Länge und den dazugehörenden Prüfsummen, im 
wirkenden Inhalt jedoch schon.
Es wird beim TO wohl die letzte Zeile beim Lesen auf jeden Fall auf 16 
Byte aufgefüllt. In der Originaldatei beginnt deshalb der letzte 
Datenblock (vorletzte Zeile) auch mit 0x0F, weil 1 Byte kürzer.

Dass der erste Record einen Prüfsummenfehler hat ist jedoch schon 
seltsam.

[Thomas Z. (usbman)]

HildeK schrieb:
> Es wird beim TO wohl die letzte Zeile beim Lesen auf jeden Fall auf 16
> Byte aufgefüllt. In der Originaldatei beginnt deshalb der letzte
> Datenblock (vorletzte Zeile) auch mit 0x0F, weil 1 Byte kürzer.

ja es ist jedoch wenn man der Namensgebung des TO vertrauen kann genau 
umgekehrt. Das ist eben das was ich nicht verstehe. Beim zurücklesen 
fehlt das letzte Byte.
Das er das Ding nicht mehr flashen kann dürfte am falschen extented 
Record liegen.

[HildeK (Gast)]

Thomas Z. schrieb:
> ja es ist jedoch wenn man der Namensgebung des TO vertrauen kann genau
> umgekehrt.
Richtig, das hab ich verwechselt. Es gibt eben mehrere zulässige 
Darstellungen.

[Bernhard S. (bernhard)]

Folgendes habe ich getan:

"original.hex" gebrannt, ATmega1284p arbeitet vorzüglich, dann 
ausgelesen und in "ausgelesene.hex" gespeichert.

Nun die "ausgelesene.hex" mehrfach versucht wieder zu brennen, sofort 
erschien immer die Fehlermeldung im Programmer.

Das ganze an mehreren ATmegas, mit verschieder Hardware wiederholt, 
immer die gleiche Fehlermeldung.

Andere hex-Files von anderen Projekten gebrannt, dann ausgelesen, das 
ausgelesene wieder gebrannt, alles bestens, vollste Zufriedenheit, 
Freudensprünge.

Das AVR-Studio 4.19 Projekt lege ich mal mit bei, vielleicht stimmen 
irgendwelche Einstellungen nicht.

Vielleicht könnte mal jemand von Euch das "original.hex" in einen 
ATmega1284p brennen, auslesen und die ausgelesene Datei wieder brennen 
und anschließend berichten.

Danke

[Bernhard S. (bernhard)]

Dieses "_LOGGER.hex" File lässt sich problemlos brennen, auslesen und 
das ausgelesene wieder fehlerfrei brennen.

Seltsam :(

[Thomas Z. (usbman)]

noch zum mitschreiben dein ausgelesen.hex ist KEIN gültiges Intel Hex 
File

Der Programmer muss das garnicht brennen. Der kann damit verfahren wie 
er will. Nimm einfach die aktuelle Version des Tools deine hat ja 
offensichtlich bugs

[Wolfgang (Gast)]

Bernhard S. schrieb:
> Das ganze an mehreren ATmegas, mit verschieder Hardware wiederholt,
> immer die gleiche Fehlermeldung.

Einer deiner Files hat in Zeile 1 immer noch die falsche Prüfsumme und 
die Files enthalten unterschiedliche viele Daten (Endadresse 0x7A80 bzw. 
0x7A81).

[MWS (Gast)]

Bernhard S. schrieb:
> "original.hex" gebrannt, ATmega1284p arbeitet vorzüglich, dann
> ausgelesen und in "ausgelesene.hex" gespeichert.
> ...
> Vielleicht könnte mal jemand von Euch das "original.hex" in einen

Vielleicht könntest Du die erste Zeile des original.hex

:020000020000FE

entweder löschen, oder mit der richtigen Prüfsumme "FC" versehen.

https://www.fischl.de/hex_checksum_calculator/

Da baut eben Dein Ausleseprogramm Murks, das ist doch klar erkennbar, 
wenn die Checksumme einer Zeile nicht stimmt.

Außer Du hast Dateien verwechselt, dann käme der Checksummenfehler 
woanders her, das sähe man am Datum/Zeitstempel.

[Bernhard S. (bernhard)]

Hurra, es funktioniert !

Thomas Z. schrieb:
> Nimm einfach die aktuelle Version des Tools deine hat ja
> offensichtlich bugs

MWS schrieb:
> Da baut eben Dein Ausleseprogramm Murks, das ist doch klar erkennbar,
> wenn die Checksumme einer Zeile nicht stimmt.

Genau, das war der richige Tipp, Danke.


Hier fand ich ein Update:

https://shop.myavr.de/index.php?sp=download.sp.php

Hab mal den ATmega mit der alten V1.39 und der neuen V.153 Version 
ausgelesen, unterschiedliche Dateien sind dabei entstanden.

Zeile 1 ist zwar noch unteschiedlich, warum auch immer.

Problem gelöst. Super.

Ein großes Dankeschön an alle :-)

Bernhard

[Thomas Z. (usbman)]

Bernhard S. schrieb:
> Zeile 1 ist zwar noch unteschiedlich, warum auch immer.
nun das ist doch ganz klar weil die Software immer noch bugs hat. Das 
wird spätestens dann ein Problem wenn mehr 64k im Spiel sind.

Schreib dem Autor der Software eine Email und verlinke auf diesen 
Thread, dann kann er seine Tools fixen. Ist halt der typische AVR 
Wildwuchs. Jder muss seine eigenen Tools frickeln.

[michael_ (Gast)]

Alles wäre kein Problem gewesen, wenn man einfaches .hex/.bin verwendet 
hätte?
Wurde abgeschmettert.

[Bernhard S. (bernhard)]

michael_ schrieb:
> Alles wäre kein Problem gewesen, wenn man einfaches .hex/.bin verwendet
> hätte?
> Wurde abgeschmettert.

Thomas Z. schrieb:
> Hexdateien zu vergleichen macht nur begrenzt Sinn. Das funktioniert nur
> wenn die RecLen in beiden Fällen gleich ist.
> Wandle deine Hex Dateien in Binär Files um und mach einen
> Binärvergleich. Entweder mit einem Tool oder im einfachsten Fall mit fc

Ganz ehrlich, Euren beschriebenen .hex/.bin Vergleich vertehe ich bis 
heute nich :(

AVRstudio produziert eine *.hex Datei im ASCII Format.

"mySmartUSB ligt" und "myAVR ProgTool" kann diese hex datei in enen µc 
brennen.

Beim Auslesen des µC entsteht wieder eine hex Datei.

Beide Dateien können z.B. mit Excel verglichen werden.
Zeitaufand ca. 1 Minute.

Wo und wie soll ein binärer Vergleich erfolgen?

Jetzt seit Ihr wieder an der Reihe...

[Thomas Z. (usbman)]

Bernhard S. schrieb:
> Beide Dateien können z.B. mit Excel verglichen werden.
> Zeitaufand ca. 1 Minute.

eher 1.5 Tage oder. Hättest du mit den Binär Daten gearbeitet, wäre das 
erst gar nicht passiert. Da beide Files ja bis auf das letzte Byte 
gleich waren.
HildeK hatte dazu ja schon was geschrieben.
Die Hex Dateien können durchaus unterschiedlich sein und trotzdem den 
gleichen Binärinhalt erzeugen. Du hast dich noch nie mit dem Aufbau von 
Intel Hex beschäftigt oder?
Dein Tool ist einfach buggy. Ich meine mich auch an 2 Threads zu 
errinnern wo es genau um diese Fragen ging.

Dein eigentliches Problem war, dass die Flashsoftware wegen der falschen 
Checksumme das flashen verweigerte, das hat hat der Hersteller wohl 
derart gefixt, dass er diese nun ignoriert. Er erzeugt aber immer noch 
den falschen Record.
Ganz ehrlich so einem Tool kann man nicht vertrauen.

[kseege (Gast)]

Die Binärdaten sind das, was im FlashROM des AVR landet,
schön hintereinander im Gänsemarsch ein Byte nach dem anderen.
Das ist das eigentlich Wichtige. Die Adreßinformation
ist implizit durch die Position der Bytes festgelegt.
Wird nicht bei Adresse Null begonnen, ist die Angabe
einer Startadresse nötig. Werden ganze Bereiche des Speichers
mittendrin nicht benötigt, müssen Platzhalter eingebaut werden.

Diese Information kann man jetzt auch im Intel Hexformat
verpacken. Es gibt aber drölfzig Millionen verschiedene
Möglichkeiten, dieselben Binärdaten als korrekte Hexdatei
darzustellen: unterschiedliche Recordlängen und komplett
verwürfelte Startadressen der Zeilen.
Trotzdem stehen immer dieselben Binärdaten drin.
Insofern funktioniert der Vergleich der Hexdateien nur dann,
wenn Inhalt UND Verpackung übereinstimmen.

Den AVR interessieren aber nur die Binärdaten, die Verpackung
ist ihm egal. Deshalb ist der Vergleich der Binärdaten die
notwendige und hinreichende Methode um festzustellen, ob
der AVR damit klarkommt.

Mit freundlichen Grüßen
Klaus

[c-hater (Gast)]

Bernhard S. schrieb:

> Ganz ehrlich, Euren beschriebenen .hex/.bin Vergleich vertehe ich bis
> heute nich :(

Dabei ist es so simpel, wenn man das Intel-Hex-Format kennt.

Die Sache ist nämlich die: es gibt unzählige verschiedene 
Repräsentationen ein- und desselben binären Inhalts in einem Hex-File, 
die aber allesamt gültig sind und letztlich wieder denselben binären 
Inhalt erzeugen.

Demzufolge macht es grundsätzlich schonmal keinen Sinn, auf Ebene des 
Hexfiles zu vergleichen, man muss auf der Binärebene vergleichen.

Leider ist auch das nicht ganz trivial, weil ein Hexfile erstens nicht 
notwendigerweise einen durchgehenden Adressraum benutzt, zweitens ein- 
und dieselbe Speicherzelle mehrfach beschreiben kann und drittens auch 
eigentlich unbenutzte Datenbereiche enthalten kann. Letzteres ist 
typisch für Hexfiles, die durch Auslesen entstehen, jedenfalls bei den 
Leseroutinen der diversen Atmel- und AVR-Studios. Die lesen nämlich 
immer den gesamten Inhalt des Speichers aus und halten sich 
sinnvollerweise nicht damit auf, entscheiden zu wollen, was davon 
tatsächlich genutzter Inhalt ist. Das können sie nämlich nach Lage der 
Dinge nicht zuverlässig tun.

Die Ausleseroutinen andere AVR-Programmersoftware benutzen hingegen 
teilweise ziemlich schwachsinnige Heuristiken, die nur dann 
funktionieren, wenn man davon ausgeht, dass vor dem Flashen des so 
gewonnenen Images ein Chip erase passiert. D.h.: man kann nicht sicher 
sein, dass das beim Auslesen gewonnene Hexfile wirklich alle vom 
Programm genutzten Datenbereiche enthält.

Zusamenfassend: Ein Vergleich von zwei Hexfiles bezüglich ihres Inhalts 
erfordert erstens einen Vergleich auf der Ebene der aus ihnen 
entstehenden Binärdaten und kann mehr als nur die Ergebnisse "gleich" 
und "ungleich" liefern, nämlich "identisch" (identische Adressbereiche 
mit identischem Inhalt), "passt soweit" (in beiden Files definierte 
Adressbereiche haben identischen Inhalt) und "definitiv ungleich" (in 
übereinstimmenden Adressbereichen gab es abweichende Inhalte).

[HildeK (Gast)]

Thomas Z. schrieb:
> HildeK hatte dazu ja schon was geschrieben.

Ja, aber nicht genug. Siehe:
c-hater schrieb:
> Die Sache ist nämlich die: es gibt unzählige verschiedene
> Repräsentationen ein- und desselben binären Inhalts in einem Hex-File,
> die aber allesamt gültig sind und letztlich wieder denselben binären
> Inhalt erzeugen.

Genau. Schon die Tatsache, dass eine Zeile 1-255 Datenbytes enthalten 
kann, macht in der HEX-Repräsentation den größten Unterschied aus. 16 
Bytes sind es zwar häufig, aber eben nicht zwingend, wie in dem Beispiel 
'ausgelesen_mit_V1.39' bei der letzten Zeile: da sind es nur 13 Bytes, 
beim Original und bei V1.53 jedoch 14 Bytes. Beides funktioniert 
richtig, weil das letzte Datenbyte 0xFF hat und ein leeres Flash eh 0xFF 
drin stehen hat.

Man könnte sich auch ein einfaches, kleines Progrämmchen schreiben, dass 
diese Unterschiede in einer selbst gewählten normierten Form in einen 
File schreibt. Dann wird auch der Vergleich von HEX-Files einfach.
Statt Excel würde ich was anderes nehmen, z.B. WinMerge.

Wie kommt ihr an die Binärfiles? Mein AVRStudio liefert keine reinen 
Binärfiles, nur den .elf (neben dem .hex). Da sind aber Pfade, Namen 
etc. drin, die in einem programmierten Prozessor imho nicht mehr 
enthalten sind.
Deshalb verstehe ich die Hinweise auf einen Binärvergleich nicht so 
richtig. Klar, man könnte sich dazu auch was selber schreiben ...

[c-hater (Gast)]

HildeK schrieb:

> Klar, man könnte sich dazu auch was selber schreiben ...

Genau das habe ich getan. Vor Jahrzehnten schon...

[Thomas Z. (usbman)]

ich hatte früher immer ein Tool von der Keil HP benutzt, das ist aber 
16Bit und deshalb nur noch umständlich zu benutzen. Ich hab auch mal was 
selbstgeschrieben, benutze aber seit längerem diese Tool
https://sourceforge.net/projects/hex2bin/
Zum Datei Vergleich benutze ich Ultra Compare aus dem UE Studio Paket. 
Das Tool Kann sowohl binär als auch Text Vergleiche durchführen. Der 
Screenshoot weiter oben ist so entstanden.

[c-hater (Gast)]

c-hater schrieb:
> HildeK schrieb:
>
>> Klar, man könnte sich dazu auch was selber schreiben ...
>
> Genau das habe ich getan. Vor Jahrzehnten schon...

Wird z.B. auch hier verwendet, um die von der Designer-Anwendung 
modifizierten Datentabellen in das finale Hex-File zu implantieren:

Beitrag "Audio Spektrum Analyzer mit ATtiny85"

Und wie schon im dortigen Thread erwähnt: Das ist .net-Code, nicht 
obfusciert. Also im Prinzip open source.

Und, selbst auf diese Art benutzt; nicht viel schlechter dokumentiert 
als viele "designated open source"-Projekte...

Nämlich praktisch nicht wirklich, aber mit hinreichender Nutzerkompetenz 
hinreichend...

[Georg (Gast)]

HildeK schrieb:
> Deshalb verstehe ich die Hinweise auf einen Binärvergleich nicht so
> richtig. Klar, man könnte sich dazu auch was selber schreiben ...

Wenn man einen Programmer hat stellt sich die Frage garnicht - ich habe 
z.B. einen Galep, ein recht bekanntes Produkt, und die Software dazu 
kann in den Speicherbereich des Chips Hexfiles, Binärfiles und 
wahrscheinlich noch einiges andere einlesen; wenn ich ein Hexfile 
einlese, sehe ich anschliessend auf dem Bildschirm den binären Inhalt. 
Ich könnte den als Binärfile ausgeben, nur besteht kein Grund das zu 
tun.

Das kann jeder professionelle Programmer, und das schon seit 40 Jahren 
oder so.

Georg

[c-hater (Gast)]

Georg schrieb:

> Wenn man einen Programmer hat stellt sich die Frage garnicht - ich habe
> z.B. einen Galep, ein recht bekanntes Produkt, und die Software dazu
> kann in den Speicherbereich des Chips Hexfiles, Binärfiles und
> wahrscheinlich noch einiges andere einlesen; wenn ich ein Hexfile
> einlese, sehe ich anschliessend auf dem Bildschirm den binären Inhalt.

Ja, das wäre üblich. Den binären Inhalt, der durch das Hexfile bestimmt 
ist. Aber was ist mit dem Rest, der NICHT dadurch bestimmt ist...

Und u.U. zwar wichtig für die Anwendung, aber nicht im Hexfile enthalten 
ist. Weil beim Auslesen eine untaugliche Anwendung verwendet wurde...

[Wolfgang (Gast)]

Könnt ihr eure Tool-Diskussion bitte in einen eigenen Thread auslagern. 
Keines der damit besser lösbaren Probleme besteht beim TO.

@Bernhard S.
Zum Vergleich der Intel-Hex Dateien gibt es deutlich einfacher 
handhabbare Tools als ausgerechnet Excel, z.B. WinMerge

[HildeK (Gast)]

Georg schrieb:
> Das kann jeder professionelle Programmer, und das schon seit 40 Jahren
> oder so.
Nicht jeder hat professionelle Tools. Und wozu braucht man denn den 
binären File? Nur für den seltenen Vergleich? Ich hatte nur gefragt, 
weil hier mehrere auf den Binärvergleich hingewiesen hatten.

Wolfgang schrieb:
> Zum Vergleich der Intel-Hex Dateien gibt es deutlich einfacher
> handhabbare Tools als ausgerechnet Excel, z.B. WinMerge

WinMerge hatte ich erwähnt, nützt aber genau dann nichts, wenn die 
HEX-Files nicht das selbe Format haben ...
Das war aber oben gegeben bis auf die letzte Datenzeile.

[michael_ (Gast)]

HildeK schrieb:
> Georg schrieb:
>> Das kann jeder professionelle Programmer, und das schon seit 40 Jahren
>> oder so.
> Nicht jeder hat professionelle Tools. Und wozu braucht man denn den
> binären File? Nur für den seltenen Vergleich?

Fast alle Programmer-Soft können das.
Pony-Prog ist nicht gerade prof.
Mein altes von 1999 hat massig Formate.
Lade dir mal Xgpro z. Bsp. für den TL866II herunter.

Hex-Editoren können das auch.

[Wolfgang W. (Gast)]

Zu den Bugs der myAVR_ProgTool Versionen beim Abspeichern der hex-Files:

Der Vergleich mit Original.hex und der mit V1.39 zeigt 2 Bugs, und zwar 
den schon weiter oben erwähnten mit der Checksumme in Zeile 1 und einen 
Fehler in der letzten gespeicherten Codezeile, wo V1.39 eine ungerade 
Byteanzahl speichert, im Bytecounter auch die Anzahl 0D zeigt aber die 
Checksumme F7 für die geradzahlige mit einem FF aufgefüllte Anzahl 
schreibt.

Die Version V1.53 hat diesen Fehler in der letzten Codezeile korrigiert, 
aber der 1. Fehler ist geblieben.

Wenn man z.B. mit Notepad++ den Fehler von FE in FC korrigiert, ist das 
mit V1.53 ausgelesene File mit dem Original identisch. Das lässt sich 
von der Console aus mit dem COMP-Befehl aus den Kindertagen des PCs 
überprüfen.

Somit kann man mit dieser Macke von V1.53 zurechtkommen.

Es bleibt natürlich der mehrmals in diesem Thread erwähnte Rat, dass 
hex-Files unterschiedliche Resultate erzielen können, vor allem wenn es 
um Firmware geht, die nicht wie hier in einem zusammenhängenden Stück 
ist.


P.S. Ich habe mit myAVR_ProgTool (mit Versionen aus dem 1.4er Bereich) 
auch schon diverse Unstimmigkeiten erlebt, bei denen das bessere 
Ergebnis nicht unbedingt mit der aktuelleren Version erzielt wurde.

MfG Wuff_W

[Thomas Z. (usbman)]

Wolfgang W. schrieb:
> P.S. Ich habe mit myAVR_ProgTool (mit Versionen aus dem 1.4er Bereich)
> auch schon diverse Unstimmigkeiten erlebt, bei denen das bessere
> Ergebnis nicht unbedingt mit der aktuelleren Version erzielt wurde.

Ich finde das schon seltsam, zumal die Jungs von myAVR ja auch 
kommerziell unterwegs sind. Sowas ist eigentlich nicht zu tolerieren.

Beitrag "myAVR MK2b fehlerhaft, Firmware / Hardware?"

das geht ja irgendwie in die gleiche Richtung.

[HildeK (Gast)]

Wolfgang W. schrieb:
> Der Vergleich mit Original.hex und der mit V1.39 zeigt 2 Bugs, und zwar
> den schon weiter oben erwähnten mit der Checksumme in Zeile 1 und einen
> Fehler in der letzten gespeicherten Codezeile, wo V1.39 eine ungerade
> Byteanzahl speichert, im Bytecounter auch die Anzahl 0D zeigt aber die
> Checksumme F7 für die geradzahlige mit einem FF aufgefüllte Anzahl
> schreibt.

Die die Checksumme der letzte Datenzeile ist korrekt!
Addiere einfach mal alle Bytes dieser Zeile, das Ergebnis ist 0x700. Die 
Summe muss auf 0x00 enden, dann ist die Checksumme gültig. In der 
Originaldatei ist sie 0x800.
Und dass das letzte Datenbyte (0xFF) fehlt, ist kein Problem: vor dem 
Schreiben in ein Flash oder EEPROM wird dieses üblicherweise gelöscht 
und hat dann trotzdem den richtigen Inhalt. Das hatte ich aber schon 
geschrieben.
Einzig die Checksumme in der ersten Zeile ist fehlerhaft. Dort ist die 
Summe 0x102 und müsste auch mit 0x00 enden.

[Wolfgang W. (Gast)]

Checksum in der letzten Zeile:
@ HildeK:
Du hast vollkommen recht! Die Checksum ist gleich, weil der Counter bei 
V1.39 um 1 niedriger (0D statt 0E) ist und durch das fehlende FF auch 
gleich F7 wird. (Dabei zeigt mir das sogar Notepad++ durch die farbige 
Kennzeichnung der Checksum an).

Mein Fehler, Sorry und Danke!

MfG Wuff_W

[HildeK (Gast)]

Wolfgang W. schrieb:
> (Dabei zeigt mir das sogar Notepad++ durch die farbige
> Kennzeichnung der Checksum an)
Leider zeigt das mein Notepad++ nicht an - nur die portable Version tut 
es.
Seltsam ...

[Stefan F. (Gast)]

HildeK schrieb:
> Leider zeigt das mein Notepad++ nicht an - nur die portable Version tut
> es.

Ich weiß nicht ob es noch so ist: Vor ein paar Jahren funktionierten 
einige Plugins nur in der 32 Bit Version.

[Wolfgang W. (Gast)]

@ HildeK:
Wegen Notepad++, Checksum - farbige Anzeige.

Vielleicht liegts daran: Ich habe die Files des TOs nach dem Download 
umbenannt in z. B. "Original.hex", weil beim Downloaden nur als 
"Original" voreingestellt war (Benutze Win 8.1 pro 64 Bit und den 
aktuellen Firefox). Notepad++ hat die Versionsnummer V8.1.2 (64 Bit).

Dann werden die korrekten Checksums in Grün ausgegeben und die falschen 
in Gelb.

MfG Wuff_W

[HildeK (Gast)]

Danke an Wolfgang und Stefan.
Die Endungen waren schon vorhanden. Ich hab auch mehrere Versionen des 
NP++ versucht. NP++ in V7.5 (32 Bit) und jetzt 8.1.2 (32 Bit und 64 
Bit); gleiches Verhalten. Gerade die neueste Portabel-Version (8.1.2) 
geholt, die zeigt es richtig an.
Vermutlich ein alter Installationsrest in der Config-Abteilung des 
installierten NP++.*
Alles unter Win7N.

*Nachtrag: War so, unter /AppData/Roaming/Notepad++ waren noch Reste der 
Vorgängerversion. Das Directory gelöscht und NP++ (V8.1.2, 64Bit) neu 
installiert - jetzt passt es.
Gut, dass ich heute erfahren habe, dass NP++ auch Intel-HEX highlighten 
kann ... 😀

Sorry für den Ausflug, weg vom eigentlichen Threadtitel, vielleicht 
hilft es mal jemandem.

[Wolfgang W. (Gast)]

Nachtrag:

Ich habe den Support von myAVR per E-Mail auf den Bug in der 1. Zeile 
hingewiesen und werde bei der nächsten Version testen, ob der Bug dann 
behoben wurde ...

MfG Wuff_W