Forum: Mikrocontroller und Digitale Elektronik HEX Datei bearbeiten und dann flashen


von Martin Wichert (Gast)


Lesenswert?

Hallo,

ich programmiere unter BASCOM in der VB sprache und flashe auch meine 
AVRs mit der BASCOM.

Nun meine Frage, gibt es eine Möglichkeit, eine kleine Änderung in der 
HEX-Datei zumachen und dann ohne BASCOM zu flashen?

Der Hintergrund ist, ich flashe eine Serie von Hardware mit einzigartige 
Seriennummer. Jedesmal muss ich die Seriennummer in BASCOM ändern und 
neu comprimieren und dann flashen.

Ich dachte mir, ich ändere die Seriennummer in der HEX-Datei und flashe 
sie wie auch immer.

Aber, ich konnte die Seriennummer in der Hex-Datei mit dem Hex-Editor 
nicht finden. Weder in String noch in Hexwert.

Wer kann mir hierzu ideen geben?

VG
Martin

von Wolfgang (Gast)


Lesenswert?

Martin Wichert schrieb:
> Wer kann mir hierzu ideen geben?

Erzeuge zwei Hex-Dateien mit verschiedenen Seriennummern und vergleiche 
die beiden Dateien. Dort wo sich etwas geändert hat, steht 
wahrscheinlich die Nummer.

von fop (Gast)


Lesenswert?

avrdude nennt sich das Programm zum Flashen von AVRs per Kommandozeile.

von fop (Gast)


Lesenswert?

Und zum Rumschnippeln in .hex Dateien gibt es srec_cat. Ob das 
allerdings einfacher zu bedienen ist als ein Programm zu schreiben, dass 
ein Stück einer .hex Datei ersetzt und die korrekte Zeilenprüfsumme 
setzt, kann man lange und ausgiebig totdiskutieren.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Wolfgang schrieb:
> Dort wo sich etwas geändert hat, steht wahrscheinlich die Nummer.
Und die Checksum.

Martin Wichert schrieb:
> eine kleine Änderung in der HEX-Datei zumachen
Ich würde die Änderungen allerdings in einer Binärdatei machen. Dann 
muss ich nicht auch noch an der Checksum drehen.

von Guido Körber (Gast)


Lesenswert?

Seriennummer auf eine fixe Adresse legen und diese dann vom Programmer 
hochzählen lassen.

von Jim M. (turboj)


Lesenswert?

Martin Wichert schrieb:
> Jedesmal muss ich die Seriennummer in BASCOM ändern und
> neu comprimieren und dann flashen.

Problem: Die Seriennummer steht dann an einer nicht vorhersehbaren 
Stelle im Flash/Hex File.

Wenn man die an eine feste Stelle packt (keine Ahnung wie, kenne Bascom 
nicht so gut) dann kann man das mit externen Tools einfach 
bewerkstelligen.

Z.B. gibt es in Python ein MergeHex als Teil des intelhex Pakets.

von Steffen W. (derwarze)


Lesenswert?

Warum nicht die Seriennummer im prozessorinternen EEProm Bereich 
speichern.
Der lässt sich auch unabhängig vom eigentlichen Programm beschreiben.
Durch setzen von Lock-Bits kann man den auch vor Manipulation schützen.
Man kann aber auch eine Möglichkeit im Programm einbauen wo die per 
Serial-Port mit Terminal eingegeben und im EEProm abgespeichert werden 
kann.

von Gerald K. (geku)


Lesenswert?

Datei mit **Hex-Editor MX** öffnen und editieren.

https://www.chip.de/downloads/Hex-Editor-MX_30351843.html

Einmal mit einer markanten Serienummer kompilieren (z.B Ziffernfolge von 
Pi 314159265359, je nach Länge der Serienummer)

Für weitere Programmkopien mit Hex-Editor MX öffnen und nach der 
markanten Serienummer suchen und mit der neuen Seriennummer 
überschreiben und abschließend speichern.

von Cyblord -. (cyblord)


Lesenswert?

Gerald K. schrieb:
> Einmal mit einer markanten Serienummer kompilieren (z.B Ziffernfolge von
> Pi 314159265359, je nach Länge der Serienummer)

Du hast halt keine Garantie dass die immer an der gleichen Stelle steht. 
Vor allem nicht nach Änderungen im Programm.
Wenn BASCOM keine Möglichkeit bietet (bei GCC ist das kein Problem) 
feste Flash Adressen zu vergeben, dann ist das Pfusch mit gewissem 
Risiko.

Eine gute "Zu Fuß" Methode ist auch das HEX einfach in ein BIN zu 
verwandeln, dann dort die Änderungen zu machen und dann wieder zurück zu 
wandeln.
Letztlich arbeiten auch viele libs für die HEX Bearbeitung so.

: Bearbeitet durch User
von Gerald K. (geku)


Lesenswert?

Cyblord -. schrieb:
> Du hast halt keine Garantie dass die immer an der gleichen Stelle steht

Daher muss man nach der ursprünglichen Seriennummer z.B 314159265359 
suchen und diese ersetzen. Verschiebungen der Stelle spielen **keine** 
Rolle. Die Sequenz 314159265359 muss natürlich eindeutig sein.

von Cyblord -. (cyblord)


Lesenswert?

Gerald K. schrieb:
> Cyblord -. schrieb:
>> Du hast halt keine Garantie dass die immer an der gleichen Stelle steht
>
> Daher muss man nach der ursprünglichen Seriennummer z.B 314159265359
> suchen und diese ersetzen. Verschiebungen der Stelle spielen **keine**
> Rolle. Die Sequenz 314159265359 muss natürlich eindeutig sein.

Ja mag gehen. Bleibt aber Pfusch.

von Schlaumaier (Gast)


Lesenswert?

Wieso machst du es nicht mit einen Hilf-Prg.

Im Hilfs-Prg. die Text-Zeile mit der Serien-Nr. neu schreiben.

Danach den Compiler starten (geht von der Command-Line aus)

Danach mit Avrdude den Code hochschieben.

Und so ganz nebenbei könntest du eine Datenbank führen, wo welche 
Serien-Nr. hin ist.


Ist für mich in VB ca. 1-2 Std. Arbeit.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Cyblord -. schrieb:
> Du hast halt keine Garantie dass die immer an der gleichen Stelle steht.
> Vor allem nicht nach Änderungen im Programm.

Na und?
Wenn neu kompiliert wird, ist die Nummer immer xxxyyyzzz, also
leicht zu finden, egal wo die steht.
Wird sowieso nachträglich geändert.

von Jobst M. (jobstens-de)


Lesenswert?

Bietet Bascom keine Optionen beim Aufruf über die Kommandozeile?

Seriennummer in include-file

Dann noch ein kleines Shell-Script:

schreibe sn in include-file
bascom -mit -optionen -zum -kompilieren -und -beenden
mv output.hex [sn].hex
sn++
next


Gruß
Jobst

von Martin Wichert (Gast)


Lesenswert?

Hallo Zusammen,

ich habe mal so wie der Wolfgang geschrieben hat, zwei HEX Dateien 
erzeugt mit unterschiedlichen Seriennummern. Dabei werden zwei Zeilen 
unterschiedlich angezeigt.

Beide haben eine 10stellige Nummer.

Habe beide Dateien in Notepad++ geöffnet und verglichen.
Die erste Datei mit der Seriennummer: 1808200202
zeigt
1
:10010000 4C0034005F0038004100160331003800 15
2
:10011000 30003800320030003000320030003200 51
die zweite Datei mit der Seriennummer: 2302070102
1
:10010000 4C0034005F0038004100160332003300 19
2
:10011000 30003200300037003000310030003200 53
Wobei die letzten zwei Ziffern farbig dargestellt werden, vermutlich ist 
es die Checksumme und die ersten 8 Ziffern, keine Ahnung, diese sind 
auch farbig.

Aber wie komme ich aus dieser Zahlen auf meine Seriennummer?

Danke im Voraus
Martin

: Bearbeitet durch Moderator
von Klaus (feelfree)


Lesenswert?

Hexadezimalsystem und ASCII code sagen dir was? Wenn ja, findest du es 
raus. Wenn nein, hast du was zu lernen, beides kannst du noch oft 
brauchen.

von W.S. (Gast)


Lesenswert?

Martin Wichert schrieb:
> Nun meine Frage, gibt es eine Möglichkeit, eine kleine Änderung in der
> HEX-Datei zumachen und dann ohne BASCOM zu flashen?
>
> Der Hintergrund ist, ich flashe eine Serie von Hardware mit einzigartige
> Seriennummer. Jedesmal muss ich die Seriennummer in BASCOM ändern und
> neu comprimieren und dann flashen.

Bleibe lieber dabei, deine Seriennummer im Quelltext zu ändern.
Gründe:
1. du weißt offenbar noch fast nix über den Aufbau von Intel-Hex 
Dateien.
2. du weißt nicht, wo und wie dein Bascom die Seriennummer ablegt.
3. du hast nicht geschrieben, ob du sowas wie eine Konstante in deiner 
Firmware damit machst oder ob du die Seriennummer lediglich für 
irgendeine Vergleichspoeration o.ä. benutzt.
4. du weißt nicht, ob Bascom aus der Seriennummer eine Integerkonstante 
oder ein Float oder beides bildet, also wie solche Zahlen bei Bascom 
überhaupt vorgehalten und benutzt werden.

W.S.

von MWS (Gast)


Lesenswert?

Martin Wichert schrieb:
> Aber wie komme ich aus dieser Zahlen auf meine Seriennummer?

In welcher konkreten Form (Data, Const, etc.) wird die SN im Code 
abgelegt?

von Wolfgang (Gast)


Lesenswert?

Martin Wichert schrieb:
> Aber wie komme ich aus dieser Zahlen auf meine Seriennummer?

Die steht da doch im Klartext drin, z.B. die erste
1
1808200202  
2
:10010000 4C0034005F0038004100160331003800 15
3
                                   1   8      
4
:10011000 30003800320030003000320030003200 51
5
           0   8   2   0   0   2   0   2

von Wolfgang (Gast)


Lesenswert?

p.s.
Eigentlich sind es die Hex-Werte der ASCII-Zeichen, also z.B. 0x30 für 
eine "0"
1
:10010000 4C0034005F0038004100160331003800 15
2
                                  31  38      
3
:10011000 30003800320030003000320030003200 51
4
          30  38  32  30  30  32  30  32
Genau genommen sind es jeweils 2 Byte pro Zeichen (bzw. 4 Hexstellen) 
wegen Uni-Code, d.h. die "00" des folgenden Bytes gehört mit dazu.

von Kaum zu glauben (Gast)


Lesenswert?

Martin Wichert schrieb:
> die zweite Datei mit der Seriennummer: 2302070102

> :10010000 4C0034005F0038004100160332003300 19

> :10011000 30003200300037003000310030003200 53
1
:10010000 4C0034005F0038004100160332003300 19
2
                                   2   3
3
:10011000 30003200300037003000310030003200 53
4
           0   2   0   7   0   1   0   2

Und beides an der gleichen Adresse.

von Wolfgang (Gast)


Lesenswert?

Kaum zu glauben schrieb:
> Und beides an der gleichen Adresse.

Sonst wäre das beim Dateivergleich wohl dumm aufgefallen. Basic ist eine 
Interpretersprache. Warum sollte sich bei solchen gleich langen 
ASCII-Zeichenketten im Code irgendetwas anderes ändern, insbesondere die 
Position.
Nur die Prüfsummen müssen in der Intel-Hex-Datei logischerweise neu 
berechnet werden, wenn man darin rumpfuscht ;-)

von Kaum zu glauben (Gast)


Lesenswert?

Wolfgang schrieb:
> irgendetwas anderes ändern, insbesondere die
> Position.

Natürlich ist das zu erwarten. Ich wollte es nur erwähnt haben, da oben 
darüber spekuliert wurde, dass das anders sein könnte,

von J. R. (yoc)


Lesenswert?

Wolfgang schrieb:
> Basic ist eine
> Interpretersprache.

In diesem Fall wohl nicht.
BASCOM
BASic COMpiler

von Manfred (Gast)


Lesenswert?

Martin Wichert schrieb:
> Habe beide Dateien in Notepad++ geöffnet

Hexfiles gucke ich mit HxD an:
https://mh-nexus.de/en/

von Wolfgang (Gast)


Lesenswert?

Manfred schrieb:
> Hexfiles gucke ich mit HxD an:
> https://mh-nexus.de/en/

Nur geht es hier um andere Hex-Dateien. Du sprichst von Binärdateien, 
die Hexadezimal angezeigt werden, Martin von Dateien im Intel Hex 
Format.

von Wolfgang (Gast)


Lesenswert?

ok - HxD kann Intel Hex importieren, falls das Format richtig stimmt und 
nicht mit Leerzeichen angereichert ist, so wie oben.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Wolfgang schrieb:
> Genau genommen sind es jeweils 2 Byte pro Zeichen (bzw. 4 Hexstellen)
> wegen Uni-Code, d.h. die "00" des folgenden Bytes gehört mit dazu.
Wenn man es schlauer machen möchte, dann codiert man die Seriennummer 
nicht als UniCode oder ASCII, sondern einfach Binär als long.

Dann müsste man bei 1808200202 nach 6BC6F20A suchen
und bei 2302070102 nach 8936CD56 (oder eben je nach Darstellung 
byteweise rückwärts). Die nächste SNr 2302070103 wäre dann 8936CD57 usw 
usf

von Martin Wichert (Gast)


Lesenswert?

MWS schrieb:
> Martin Wichert schrieb:
>> Aber wie komme ich aus dieser Zahlen auf meine Seriennummer?
>
> In welcher konkreten Form (Data, Const, etc.) wird die SN im Code
> abgelegt?

Hallo,
Die Sn wird als Consrante gelegt.

von Klaus (feelfree)


Lesenswert?

> Die Sn wird als Consrante gelegt.

Konstante meintest du wohl.
Aber sie landet als unicode im binary, wie du ja mit deinem hex-file 
gezeigt hast.

von H.Joachim S. (crazyhorse)


Lesenswert?

Martin Wichert schrieb:
> neu comprimieren

Martin Wichert schrieb:
> Consrante

Rechtschreibschwäche? Hektik? Fehlerhafte KI?
Ich tippe mal auf android, mir ist es bis heute nicht gelungen den 
scheinbar intelligenten Quark abzuschalten.

von michael_ (Gast)


Lesenswert?

Normalerweise legt man sowas am Ende des Speichers ab.
Und nicht in Mitten vom Programm.

Wenn man es nicht mit BASCOM schafft, der kann auch Assembler.
Und Änderungen nicht mit Intel-Hex.
Das hin und her wandeln zu bin kann doch jeder Programmer.

Aber wie oben schon vermerkt, ich würde das im EEPROM ablegen.
Den kann man ja auch getrennt vom Flash programmieren.

von Martin Wichert (Gast)


Lesenswert?

Wolfgang schrieb:
> p.s.
> Eigentlich sind es die Hex-Werte der ASCII-Zeichen, also z.B. 0x30 für
> eine "0":10010000 4C0034005F0038004100160331003800 15
>                                   31  38
> :10011000 30003800320030003000320030003200 51
>           30  38  32  30  30  32  30  32
> Genau genommen sind es jeweils 2 Byte pro Zeichen (bzw. 4 Hexstellen)
> wegen Uni-Code, d.h. die "00" des folgenden Bytes gehört mit dazu.

Hi Wolfgang,

ich habe das mal in VB.NET versucht die erte Zeile zu berechnen.

  Dim v1 = &H4C00
        Dim v2 = &H3400
        Dim v3 = &H5F00
        Dim v4 = &H3800
        Dim v5 = &H4100
        Dim v6 = &H1600
        Dim v7 = &H3100
        Dim v8 = &H3800

        Dim sum As Integer

        sum = v1 + v2 + v3 + v4 + v5 + v6 + v7 + v8
        Dim overflow = sum \ 256
        Dim modulo = sum Mod 256
        sum = Not (CByte((overflow + modulo) Mod 256))

        MsgBox(sum)

leider bekomme ich als Checksumme 40 statt die 15

von Christian M. (christian_m280)


Lesenswert?

Wolfgang schrieb:
> Uni-Code

UTF-16 wohl in diesem Fall... Für Mikrocontroller nicht so ideal...

Gruss Chregu

von Forist (Gast)


Lesenswert?

Martin Wichert schrieb:
> leider bekomme ich als Checksumme 40 statt die 15

In die Prüfsumme gehört auch der Record Identifier und die Adresse mit 
rein.
(s. Wikipedia Intel HEX)

von Martin Wichert (Gast)


Lesenswert?

Forist schrieb:
> Martin Wichert schrieb:
>> leider bekomme ich als Checksumme 40 statt die 15
>
> In die Prüfsumme gehört auch der Record Identifier und die Adresse mit
> rein.
> (s. Wikipedia Intel HEX)

Hi,

aus der Kette berechnet auf der Seite von Wikipedia 
https://de.wikipedia.org/wiki/Intel_HEX#Berechnung_der_Pr%C3%BCfsumme
kommt 3C0 -> C0 = 40

wie ist das bitte zu verstehen?

von Klaus (feelfree)


Lesenswert?

Martin Wichert schrieb:
> wie ist das bitte zu verstehen?

Du solltest halt alles lesen, inkl. der Erklärung zum Zweierkomplement.

von Schlaumaier (Gast)


Lesenswert?

Das Problem ist in VB geschrieben ein 40 Prg-Zeilen Programm.

Dann gibt man die NEUE Serien-Nr. ein und das VB Programm schiebt 
automatisch das passenden Programm in den Chip mit der neuen Serien-Nr.

Jobst M. schrieb:
> Bietet Bascom keine Optionen beim Aufruf über die Kommandozeile?

Doch tut es.   Ist Grundlage meiner Aussage.

Funktionieren würde meine Idee so.

Mann gibt die neue Serien-Nr. in VB ein.

VB Kopiert nun den Code (Seriall-Read-Write) und ändert die Zeile um in 
der die Serien-Nr steht. Dazu einfach nach den Kommentar zu der Zeile 
suchen.

Danach wird über die Shell der Bascom-Compiler aufgerufen.

Und danach AVRdude um das Ergebnis in den Chip zu schieben.

Fertig ist das ganze.  Und vor allen Dingen Risiko-Frei. Da man auf die 
Weise genau das selbe macht was man auch in der IDE macht.

von MWS (Gast)


Lesenswert?

Martin Wichert schrieb:
> MWS schrieb:
>> Martin Wichert schrieb:
>>> Aber wie komme ich aus dieser Zahlen auf meine Seriennummer?
>>
>> In welcher konkreten Form (Data, Const, etc.) wird die SN im Code
>> abgelegt?
>
> Hallo,
> Die Sn wird als Consrante gelegt.

Mach's halt nicht so kompliziert und kopiere die betreffenden Codezeilen 
hier rein.

Wenn das Ablegen im Code geeignet statt findet, dann würde Dir das 
Wiederfinden der jeweiligen Stelle im Hex einfacher fallen.

Es gibt in Bascom mehrere Formen von konstanten Daten, nähme ich 
"Constante" wörtlich, wäre es ein Const, das sähe so aus:
1
Const SNr = 2302070102 ' numerische Konstante
oder
1
Const SNr = "2302070102" ' Stringkonstante
Mit der Konstante findet in dieser Form ein Textersatz statt, so wie es 
in C mit #define erledigt wird. Überall wo im Code "SNr" verwendet wird, 
trägt der Compiler die numerische oder Stringkonstante ein.

Das geht auch andersrum: Wird über Const eine Konstante definiert, 
jedoch nie verwendet, so findet sie sich nicht im Flash und damit im Hex 
wieder, die geht dann zur Kompilierzeit verloren.

Wenn die Seriennummer tatsächlich so verkrumpelt im Flash liegt, wie es 
der Thread hier annehmen lässt, dann dürfte das Deine Absicht sein, z.B. 
um diese zu verschleiern.

Denn würdest Du schreiben:
1
SerNrLbl:
2
Data 2302070102&
3
Data "2302070102"
so fändest Du die Seriennummer im Flash in dieser Form wieder:
--> 0x56 0xCD 0x36 0x89
und als ASCII
-- > 0x32 0x33 0x30 0x32 0x30 0x37 0x30 0x31 0x30 0x32

von michael_ (Gast)


Lesenswert?

Ich verstehe das Getöse nicht!
Ob man das in BASCOM auf eine bestimmte Speicherzelle positionieren 
kann, Habe ich auf die Schnelle bei Claus Kühnel nicht gefunden.
Ich habe auch die Vollversion von BASCOM, habe aber keine Lust die 
Hausaufgaben des TO zu machen.
Aber wie oben schon erwähnt, geht das mit eingebundenem Assembler 
problemlos.
Einfach ein ORG. und dann die Zeichenkette.

Diese Adresse kann man doch leicht vor der Programmierung in der .bin 
Datei ändern.

Die umwandlung von dez nach hex wird man doch wohl noch fertig bringen.

von Cyblord -. (cyblord)


Lesenswert?

michael_ schrieb:
> Aber wie oben schon erwähnt, geht das mit eingebundenem Assembler
> problemlos.
> Einfach ein ORG. und dann die Zeichenkette.

Und der BASCOM Compiler bzw. Linker nimmt dann darauf Rücksicht?

von MWS (Gast)


Lesenswert?

Cyblord -. schrieb:
> Und der BASCOM Compiler bzw. Linker nimmt dann darauf Rücksicht?

Macht er.
Nur nicht so wie michael_ es kennt oder annimmt, sonst würde er es nicht 
empfehlen.

Man kann die gewünschte Information ganz zu Anfang des Programms 
ablegen:
1
Goto SerEnd
2
  Data "         ", "SNR", "2302070102"
3
SerEnd:
Mit 99,9% Wahrscheinlichkeit wird sich an der Ablageadresse nichts 
ändern, solange man die Position im Code nicht ändert und der Compiler 
in einer späteren Version seinen Startupcode nicht ändert.

Möchte man ganz sicher sein, dann sucht man im Hex nach "SNR" plus 
Terminator, das ist mit 534E5200 zu finden, was folgt ist die 
Seriennummer in ASCII, Auszug aus dem Hex:

:1000B0002000534E5200323330323037303130323C

Die 9 Leerzeichen sind Füllbytes, damit alles in eine Hex-Zeile passte.
Alternativ:
1
Goto SerEnd
2
  Data "SNR", 2302070102&
3
SerEnd:
Resultat im Hex:

:1000A000E9F766240C945800534E520056CD368919

Die Seriennummer steht als 56CD3689 dort, LSB zuerst.

Zum verpönten Goto, das muss hier sein, sonst würden diese Flash-Daten 
als Anweisung interpretiert. Ein "End" als Markierung für das 
Programmende darf mit der Methode nicht verwendet werden, sonst gibt's 
Mecker.

von Boomer (Gast)


Lesenswert?

michael_ schrieb:
> Normalerweise legt man sowas am Ende des Speichers ab.
> Und nicht in Mitten vom Programm.

Und damit ist die Sache doch erledigt.

Pack die Seriennummer an eine definierte Stelle im Flash/EEPROM anstatt 
irgendwas im Firmware File zu ersetzen. Wie soll denn da ein Firmware 
Update sonst praktikabel möglich sein?

Teils haben uC bereits ab Werk eine Seriennummer, ggf. ist die etwas für 
dich.

von SvenB. (Gast)


Lesenswert?

Also das Compilat als Bin File speichern. Nicht Intel Hex ich habe das 
Programmtechnisch schon hinter mir, da musste erst mal lesen, dann 
Analysieren dann Encodieren änder und wider Codieren macht mehr aufwand. 
Schneller ist das als Bin File, da musste nur den Seriencode ändern, 
oder wie schon beschrieben über die Serielle Schnittstelle nach dem 
Programmieren die Seriennummer eintragen lassen, oder eben immer neu 
Compilieren mit einer neuen Seriennummer.

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.