Binärformate: intel HEX => BIN (ARM CortexM3)

[Tobias (Gast)]

Hallo, ich komme gerade nicht weiter.

Ich habe ein STM32 Discovery Board vor mir liegen und möchte das einmal 
beliebig flashen zur probe. Ein SW Tool (stlink, 
https://github.com/texane/stlink) hab ich, das nimmt aber anscheinend 
nur .bin files - ich habe aber nur Beispiele im hex Format vorliegen.

Wie kann ich das schnell umwandeln??
Wenn ich mir das so überlege, dann besteht ein hex-file ja aus den 
ASCII-codierten roh-code (+ checksummen, adressen), ein .bin hingegen 
ist ja der Maschinencode pur ( also ohne Prüfsummen und Offsetadressen). 
Oder irre ich mich da ?

Grüße

[Sascha W. (sascha-w)]

such mal nach "hex2bin"

Sascha

[Georg G. (df2au)]

Wikipedia hat einen Artikel über das Intel-Hex Format.

[Tobias (Gast)]

@Sacha: Ja hex2bin gibts irgendwie von Keil, gleub nicht dass das unter 
Linux läuft.

@Georg. Ja den Artikel kenne ich, aber ob meine These zum Zusammenhang 
der Formate richtig ist weißt du auch nicht ?

[Georg G. (df2au)]

Deine Annahme über bin-Files sind richtig.

[holger (Gast)]

>@Sacha: Ja hex2bin gibts irgendwie von Keil, gleub nicht dass das unter
>Linux läuft.

Nimm srecord. Das kann auch Intel HEX.

[Tobias (Gast)]

srecord, hab ich soeben versucht. der macht mir aus 2,7 MB  hex  ein 130 
MB großes file.

zweiter Vesuch war "objcopy -Iihex -Obinary in.hex out.bin" .

da kommen dann 900KB raus .- das sieht schon realistischer aus.

st-flash bringt mir aber einen ERROR, kA wieso.

[
open(out_.bin) == -1
2012-09-14T19:05:51 WARN src/stlink-common.c: map_file() == -1
stlink_fwrite_flash() == -1

]

[holger (Gast)]

>zweiter Vesuch war "objcopy -Iihex -Obinary in.hex out.bin" .

objcopy ist auch gut.

>da kommen dann 900KB raus .

Wie viel Flash hat dein Controller?

[Tobias (Gast)]

1MB Flash misst der Flash des Controllers

[holger (Gast)]

>1MB Flash misst der Flash des Controllers

Passt doch;)

Nimm lieber die ELF Datei wenn du mit objcopy arbeitest.
So holen wir eine BIN aus der ELF:

arm-none-eabi-objcopy -O binary -j .text -j .data -j.ARM.exidx 
--gap-fill 0xFF %1.elf %1.bin

Bin mir aber nicht sicher ob -j .data -j.ARM.exidx wirklich nötig sind.

[Tobias (Gast)]

nein eine ELF hab ich nicht, eine etwa ein drittel so große *.DFU Datei 
ist noch im binary Ordner. Davon hab ich aber noch nie gehört.

[holger (Gast)]

>st-flash bringt mir aber einen ERROR, kA wieso.
>open(out_.bin) == -1

Deine Datei heisst doch out.bin und nicht out_.bin.

[Tobias (Gast)]

nein, out.bin war die die mit srecord erstellt wurde. Sorry - für die 
Verwirrung.

[Tobias (Gast)]

Nochmal sorry für weitere Verwirrung. Irgendwie klappt gerade das 
programmmieren das Flash mit dem objcopy erstellen file. Vielen Dank!!

[r Inform (Gast)]

Nur zur Info:

$ st-flash  write fancyblink.elf 0x8000000
2012-09-14T20:51:20 INFO src/stlink-common.c: Loading device 
parameters....
2012-09-14T20:51:20 INFO src/stlink-common.c: Device connected is: F1 
Medium-density Value Line device, id 0x10016420
2012-09-14T20:51:20 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 
KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2012-09-14T20:51:20 INFO src/stlink-common.c: Attempting to write 84806 
(0x14b46) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08014800 erased
2012-09-14T20:51:22 INFO src/stlink-common.c: Finished erasing 83 pages 
of 1024 (0x400) bytes
2012-09-14T20:51:22 INFO src/stlink-common.c: Starting Flash write for 
VL core id
2012-09-14T20:51:22 INFO src/stlink-common.c: Successfully loaded flash 
loader in sram
 82/82 pages written
2012-09-14T20:51:27 INFO src/stlink-common.c: Starting verification of 
write complete
2012-09-14T20:51:29 INFO src/stlink-common.c: Flash written and 
verified! jolly good!

$


Jolly good!

[r Inform (Gast)]

>Jolly good!

Jolly better wäre allerdings, wenn er das elf nicht als Binärfile
flashen würde... :-)