Hi, ich will eine Datei eeprom.bin erzeugen, welche exakt 512 kB groß sein muss, damit das ganze EEPROM mit definierten Daten überschrieben wird. Dafür habe ich drei Dateien a.bin b.bin und c.bin, die an verschiedene Stellen geschrieben werden müssen. Die Größen sind je nach Build variabel. Die Lücken zwischen den Dateien und auch der Bereich bis zum Ende sollen mit 0xFF gefüllt werden. Wie mache ich das? Ich probiere schon eine halbe Ewigkeit mit srec_cat herum und kriege es nicht hin. Meine Idee war: srec_cat -output eeprom.bin -binary a.bin -binary -offset 0x00000 b.bin -binary -offset 0x10000 c.bin -binary -offset 0x60000 -fill 0xFF 0x70000 0x80000 Aber so sind die Lücken mit 0 gefüllt (darf nicht sein), bis auf das Ende eben. Wenn ich -fill 0xFF 0x00000 0x80000 an den Anfang stelle, meckert er, dass sich Werte widersprechen. Irgendwie auch klar, aber ich dachte, er überschreibt die nachher mit den Dateien.
Hallo! Ich nutze für solche Anwendungen schon lange Hex-Editoren. z.B. hat die Freeware wie: http://mh-nexus.de/de/hxd/ bisher alle meine Anforderungen erfüllt. Verketten mehrerer Dateien, Eingeben von Daten mit der Hand, Löschen von Bereichen, Ausschneiden, Kopieren, Einfügen, Suchen usw. usw. Alles kein Problem.
Das Ganze müsste schon per Kommandozeile (für ein Makefile) lösbar sein.
Frank schrieb: > Wenn ich -fill 0xFF 0x00000 0x80000 an den Anfang stelle, meckert er, > dass sich Werte widersprechen. Irgendwie auch klar, aber ich dachte, er > überschreibt die nachher mit den Dateien. Das sollte auch möglich sein. Anscheinend kann man diesen Error mit der 'contradicting bytes' option abstellen, aber ich werd aus der Doku nicht recht schlau, wie das funktioniert. In der Doku sind einige Optionen im Textteil erwähnt, die in der Optionenbeschreibung nicht mehr auftauchen. Und der Source Code ist zu umfangreich, um das auf die schnelle zu ergründen. Frag den Autor, wie das funktioniert. Befriedigend ist diese Lösung nicht gerade, denn wenn sich deine Datenfiles überschneiden willst du ja eine derartige Warnung bzw. Fehler haben. Ideal wäre es, wenn es einen Defaultwert für nicht durch Datenfiles abgedeckte Speicherbereiche gäbe. Schliesslich gibt es keinen Grund, warum da überall 0x00 drinn stehen soll.
Hast du mal folgendes versucht?
1 | srec_cat -output eeprom.bin -binary a.bin -binary -offset 0x00000 b.bin |
2 | -binary -offset 0x10000 c.bin -binary -offset 0x60000 -fill 0xFF 0x00000 |
3 | 0x80000 |
Laut Doku weiß srec_cat welche Bereich mit Daten aus den Inputfiles gefüllt worden sind und füllt nur die Lücken. Deshalb könnte es funktionieren wenn du als Startadresse 0x00000 und nicht 0x70000 verwendest.
Wie gesagt, dann meckert er und bricht ab:
1 | 0x0080: contradictory 0x00000000 value (previous = 0xE9, this one = 0xFF) |
SF schrieb: > Laut Doku weiß srec_cat welche Bereich mit Daten aus den Inputfiles > gefüllt worden sind und füllt nur die Lücken. Dann könnte man das doch im Quelltext nach eigenen Wünschen ändern und entweder fest statt 00 0xFF als Füllmuster verwenden oder eventuell mit einem eigenen Schalter '-gap' für "Lücke". Das compiliert man dann einfach zu einem eigenen srec_cat.
Neee, das ist Mist. Ich will zu meinem Projekt nicht auch noch ein angepasstes Standardtool veröffentlichen. Das gibt's doch nicht! Ist doch eigentlich eine ganz einfache Problemstellung, wie sie oft vorkommen sollte (0xFF ist standardmäßig unprogrammiert bei EEPROMs). Da muss es doch eine Lösung geben.
So sollte es gehen:
1 | srec_cat a.bin -bin -off 0x00000 \ |
2 | -gen -maximum-addr a.bin -bin 0x10000 -const 0xFF \ |
3 | b.bin -bin -off 0x10000 \ |
4 | -gen -maximum-addr ( b.bin -bin -off 0x10000 ) 0x60000 -const 0xFF \ |
5 | c.bin -binary -offset 0x60000 \ |
6 | -gen -maximum-addr ( c.bin -bin -off 0x60000 ) 0x80000 -const 0xFF \ |
7 | -o eeprom.bin -bin |
CU
Danke, scheint zu klappen (allerdings ohne die Klammern!).
1 | srec_cat ( a.bin -bin b.bin -bin -off 0x10000 c.bin -bin -off 0x60000 ) -fill 0xFF 0x00000 0x80000 -o out.bin -bin |
So funktioniert es aber auch! Eben ausprobiert mit der recht alten srec_cat Version 1.47.D001. Bei mehreren Files braucht es anscheinend die Klammern (Leerzeichen vorher und nachher sind wichtig!), damit der -Fill Filter auch wirklich auf allen Dateien wirkt und nicht nur auf der letzten angegebenen Input-Datei. Ich benutze für ein Projekt auch den -Fill Filter, allerdings nur mit einer Input-Datei, und da hat ein -Fill über den gesamten Adressbereich immer die ohne Probleme funktioniert!
Hier geht nur die Variante von FBI und nur ohne Klammern (sonst Syntaxfehler).
Bei mir gehts mit und ohne Klammern. Und die Variante von SF geht ebenfalls. Hab die 1.64.D001 CU
Hab's nicht probiert, aber das müsste doch auch ganz ohne zusätzliches Programm allein mit objcopy gehen? objcopy kennt die Optionen
1 | --add-section sectionname=<datei> |
(damit lassen sich zusätzliche Dateien anfügen) und
1 | --gap-fill=<value> |
(damit kannst Du bestimmen, wie die Lücken aufgefüllt werden sollen).
:
Bearbeitet durch User
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.