von ELF nach flashbarem Format mit objcopy

[J. V. (janvi)]

möchte ein (prima funktionierendes) ELF zum flashen an dritte weggeben. 
Der ST-Link für STM32 versteht aber kein elf sondern nur binary, Intel 
oder Motorola hex.

1) Gibt es für STM32 Gründe besser Intel oder Motorola zu nehmen ?
2) warum gelingt mir die Binary Version nicht ?

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ ls
out.elf

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ arm-none-eabi-objcopy -O ihex out.elf out.hex

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ arm-none-eabi-objcopy -O binary out.elf out.bin
C:\programme\gcc\bin\arm-none-eabi-objcopy.exe: Unable to recognise the format of the input file `out.elf'

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ ls
out.elf  out.hex

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$

[pegel (Gast)]

Gib dem arm-none-eabi-objcopy noch ein -v mit, vielleicht erfährst du 
mehr.

[Bernd K. (prof7bit)]

nicht daß ich glaube daß es was damit zu tun hätte, aber bei mir wird 
auch noch --strip-all mit angegeben. Also z.B.

arm-none-eabi-objcopy -O ihex -S build/hello_world.elf build/hello_world.hex
arm-none-eabi-objcopy -O srec -S build/hello_world.elf build/hello_world.s19
arm-none-eabi-objcopy -O binary -S build/hello_world.elf build/hello_world.bin

Läuft alles schön durch bei mir.

[Dr. Sommer (Gast)]

Zeig doch mal deine ominöse ELF Datei... Wie genau wird die überhaupt 
erstellt? Wenn objcopy das Format nicht erkennt hilft ggf. die explizite 
Übergabe:

arm-none-eabi-objcopy -I elf32-littlearm -O binary out.elf out.bin

[J. V. (janvi)]

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ arm-none-eabi-objcopy -v -O srec out.elf out.s19
copy from `out.elf' [ihex] to `out.s19' [srec]

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ arm-none-eabi-objcopy -v -O binary out.elf out.bin
copy from `out.elf' [ihex] to `out.bin' [binary]
C:\programme\gcc\bin\arm-none-eabi-objcopy.exe: Unable to recognise the 
format of the input file `out.elf'

genau gleich auch mit strip, verbose bringt keine erleuchtende Meldung 
und  der S-record wird genauso wie der Intelhex erzeugt. Könnte es daran 
liegen, dass der Vektorbereich nicht zusammenhängend mit dem Code ist 
und das im binary schlecht dargestellt / aufgefüllt werden kann ?

[Bernd K. (prof7bit)]

J. V. schrieb:
> arm-none-eabi-objcopy -v -O binary out.elf out.bin
> copy from `out.elf' [ihex] to `out.bin' [binary]

Da ist doch was faul! Warum ist Dein .elf angeblich "ihex"?


So sieht das bei mir aus (beachte: elf32-littlearm):

arm-none-eabi-objcopy -O binary -v -S build/hello_world.elf build/hello_world.bin
copy from `build/hello_world.elf' [elf32-littlearm] to `build/hello_world.bin' [binary]

[J. V. (janvi)]

das wars wohl:

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ arm-none-eabi-objcopy -I elf32-littlearm -O binary out.elf out.bin

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ ls
out.bin  out.elf  out.hex  out.s19

jv@OSIRIS /cygdrive/c/data/cad/job/swagelok/fw/Objects
$ cat out.bin|more
▒`1`▒H▒%▒&I▒▒s"+▒▒`j`)F▒H▒▒"F▒HO▒▒8+▒▒`)F▒H▒|▒#O▒
▒O▒▒▒O▒ʀO▒%
▒O▒r▒F▒▒M▒L▒́gH▒▒▒▒3▒eH)FfO▒▒)FbH▒▒▒":p▒@▒#"FHH)F▒▒▒FH)F▒z▒DH)F▒▒▒*F)FAH 
▒▒AH▒.▒@IAK&
                                                                                   `@K▒`K`▒#Ka▒▒a▒@s▒a▒▒xs
                                                                                                          b▒`^LaLb▒b5H▒▒▒3H)F▒▒5IO▒`#▒`^L`M`▒`^Lau2H▒T.......

Geflasht krieg ichs aber nicht nicht weil ein Offset von 0x0800.0000 
fehlt. Offensichtlich kann man am ST-Link Utility keine manuelle 
Startadrese eingeben.

Was ich in diesem Zusammenhang auch nicht versteht: Lt. Datenblatt ist 
die Vektortabelle ab Adresse 0. Zumindest im Memory Dump sieht man sie 
dort auch. Der Compiler legt sie aber bei 0x0800.0000 an den Codeanfang. 
Der Inhalt stimmt schon. Das erste Langwort ist der Stackpointer mit 
0x20002800 und mein Low Density Ram geht bis 0x200027ff (predecrement). 
Der Flash Bereich scheint im Chip komplett gespiegelt zu sein? aber zum 
Flashen gehts dort nicht.

[pegel (Gast)]

Wie? Du zwingst ihn jetzt die Datei als elf zu betrachten?

Probier erst mal:
arm-none-eabi-objdump -p out.elf

[pegel (Gast)]

Sollte etwas in der Art erscheinen

TFT.elf:     file format elf32-littlearm

Program Header:
    LOAD off    0x00010000 vaddr 0x08000000 paddr 0x08000000 align 2**16
         filesz 0x00005110 memsz 0x00005110 flags rwx
    LOAD off    0x00020000 vaddr 0x20000000 paddr 0x08005110 align 2**16
         filesz 0x00000008 memsz 0x000000b4 flags rw-
    LOAD off    0x000200b4 vaddr 0x200000b4 paddr 0x08005118 align 2**16
         filesz 0x00000000 memsz 0x00000604 flags rw-
private flags = 5000200: [Version5 EABI] [soft-float ABI]

[Dr. Sommer (Gast)]

J. V. schrieb:
> Zumindest im Memory Dump sieht man sie
> dort auch. Der Compiler legt sie aber bei 0x0800.0000 an den Codeanfang.
Das ist schon richtig. Bei (fast?) allen Cortex-M Controllern ist der 
Flash bei 0x08000000 zu finden. Manche wie der STM32 können den 
zusätzlich an die 0-Adresse spiegeln je nach Einstellung der BOOT*-Pins 
und des SYSCFG Registers. An 0x08000000 zu flashen/lesen ist aber der 
sichere Weg, weil der Flash dort immer zu finden ist.

J. V. schrieb:
> Das erste Langwort ist der Stackpointer mit
> 0x20002800 und mein Low Density Ram geht bis 0x200027ff (predecrement).
Ja ist richtig so.

Es sieht so aus als würde dein erster objcopy Befehl deine out.elf aus 
irgendwelchen Gründen mit ihex überschreiben, sodass der zweite Aufruf 
scheitert? Vertausche die Befehle mal, oder führe unmittelbar vor dem 
zweiten ein "arm-none-eabi-readelf -S out.elf" aus um die Datei zu 
überprüfen.

[Bernd K. (prof7bit)]

Poste doch mal den ganzen Build-output (wo man alle Tool-Aufrufe mit 
allen Argumenten sieht, insbesondere alle Teile die out.elf betreffen)

[Bernd K. (prof7bit)]

arm-none-eabi-objcopy -O ihex -S out.elf out.elf

statt

arm-none-eabi-objcopy -O ihex -S out.elf out.hex

läuft nämlich ohne Warnung durch und überschreibt das elf file ohne 
mit der Wimper zu zucken. Danach käme dann beim Versuch daraus noch ein 
.bin zu erzeugen exakt die Fehlermeldung von oben.

Überprüfe also Dein Build-Script auf einen derartigen Tippfehler.

[J. V. (janvi)]

ja ja ich weiss, wahrscheinlich habe ich den falschen GCC und viel zu 
alt:

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2    -save-temps      -I.\ -o .\objects\cpuinit.o .\cpuinit.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2       -I.\ -o .\objects\flop.o .\flop.c

arm-hitex-elf-gcc.exe  -Wall  -O0  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2       -I.\ -o .\objects\main.o .\main.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\misc.o .\misc.c

arm-hitex-elf-as.exe  -gdwarf2  -mcpu=cortex-m3  -mthumb    -I.\ -o 
.\objects\startup_stm32f10x_ld.o .\startup_stm32f10x_ld.s

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections         -I.\ -o .\objects\stm32f10x_adc.o 
.\stm32f10x_adc.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\stm32f10x_dma.o 
.\stm32f10x_dma.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\stm32f10x_flash.o 
.\stm32f10x_flash.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\stm32f10x_gpio.o 
.\stm32f10x_gpio.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\stm32f10x_it.o 
.\stm32f10x_it.c

arm-hitex-elf-gcc.exe  -Wall  -Os  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\stm32f10x_rcc.o 
.\stm32f10x_rcc.c

arm-hitex-elf-gcc.exe  -Wall  -O0  -funsigned-char  -xc  -mlittle-endian 
-mthumb  -mno-thumb-interwork  -c  -mcpu=cortex-m3  -mno-tpcs-frame 
-gdwarf-2 --function-sections       -I.\ -o .\objects\stm32f10x_tim.o 
.\stm32f10x_tim.c

arm-hitex-elf-ld.exe  -T.\link.ld.tmp  -Map=file.map  --cref 
-gc-sections    -o .\objects\out.elf

sparmed52-Options:
 -V
-Reload
-S"..\..\"
-S"..\"
-S".\"
-S"..\..\Sonde\"
Dest-Directory:.\objects\

HiTOP5 symbol loader for ARM ELFDWARF
Copyright (c) 1997-2006          Hitex Development Tools GmbH
Version: 5.20.736.0 (BE: Dec 29 2008, FE: Aug  6 2009)
Include module "cpuinit"
Include module "flop"
Include module "main"
Include module "misc"
Include module "startup_stm32f10x_ld"
Include module "stm32f10x_adc"
Include module "stm32f10x_dma"
Include module "stm32f10x_flash"
Include module "stm32f10x_gpio"
Include module "stm32f10x_it"
Include module "stm32f10x_rcc"
Include module "stm32f10x_tim"
Writing blocks
Writing symbols
Object file statistic
---------------------
Code Size:     10136
Publics:       176
Types:         488
Modules:       12
Symbols:       1713
Source files:  12
Source lines:  9528

Object File ".\out.elf" successfully processed
Used memory:    2352 kByte,    Used disk space:    7 kByte

[J. V. (janvi)]

Auwei das Problem sitzt meistens vor dem Bildschirm: Das ELF war wirklch 
ein ihex vom rumprobieren in der Kommandozeile. Neu Compilieren hats 
dann wieder gerichtet und schon läuft auch objcopy in allen Formaten. 
Beim STM32 kann man den Offset fürs Binary dann übrigens beim Flashen 
angeben. Nur der automatische Erase/Program/Verify kanns (vielleicht) 
nicht mit Offset. Zwischendurch ist mir die Hardware mit einer 
Qualmwolke um die Ohren gefolgen. Ein Antrieb mit 20 Amp. War eindeutig 
statische Aufladung von meinen Turnschuhen auf dem Teppich. Hatte das so 
extrem auch noch nicht erlebt.

[J. V. (janvi)]

ääh noch was: Könnte objcopy nicht auch ein vernünftige Symbolliste mit 
absoluten Adressen schreiben ? Der Live Update im Device Memory vom 
ST-Link Utility ist doch ganz nützlich und selbst ohne Disassembler 
könnte man sich im Einzelschritt noch etwas orientieren

[Bernd K. (prof7bit)]

J. V. schrieb:
> Könnte objcopy nicht auch ein vernünftige Symbolliste mit
> absoluten Adressen schreiben ?

1. Die solltest Du schon haben:

-Map=file.map im Linkeraufruf hast Du ja schon drinstehen

2. Ein Assemblerlisting ist auch immer ganz nett, das folgende hab ich 
standardmäßig in allen meinen Makefiles

arm-none-eabi-objdump -d out.elf > out.lst

[J. V. (janvi)]

.bss ist im mapfile nicht nach aufsteigenden Adressen sortiert und im 
ST-Link Utility bezieht sich die Einstellung "Live-Update" nur auf den 
Core-Zustand und nicht auf das Target-Memory Fenster. Dieses wird aber 
beim Anstossen über die Enter Taste aktualisiert. Kann man also mit 
beidem leben und ansonsten gbts noch ächde Debugger wo das ELF wieder 
lesen kann (so kein ihex drinnensteht).

[Jörg W. (dl8dtl) (Moderator)]

J. V. schrieb:
> Der ST-Link für STM32 versteht aber kein elf sondern nur binary, Intel
> oder Motorola hex.

Der Hardware ist das Dateiformat egal. ;-) Wenn du openocd zum Flashen
benutzt, kannst du auch direkt die ELF-Dateien flashen, und musst dich
nicht um irgendwelche Offsets kümmern.

Ansonsten würde ich aufgrund des Offsets einfach keine Binärdatei in
Betracht ziehen, sondern nur Intel Hex oder Motorola S-Record, denn
die können beide die Adressinformation direkt weiterreichen.

[JV (Gast)]

Um genau zu sein: Ich habe das ST-Link Utility gemeint. Das Kabel zum 
Utility
ST-Link ist nur für Kunden als Billiglösung um Updates zu flashen damit 
ich nicht soviel nutzlos auf der Welt rumreisen muss. Selbst benutze ich 
natürlich auch einen "richtigen" Debugger und mein Favorit als Kabel ist 
von Segger

[Ruediger A. (Firma: keine) (rac)]

Dr. Sommer schrieb:
> J. V. schrieb:
>> Zumindest im Memory Dump sieht man sie
>> dort auch. Der Compiler legt sie aber bei 0x0800.0000 an den Codeanfang.
> Das ist schon richtig. Bei (fast?) allen Cortex-M Controllern ist der
> Flash bei 0x08000000 zu finden. Manche wie der STM32 können den
> zusätzlich an die 0-Adresse spiegeln je nach Einstellung der BOOT*-Pins
> und des SYSCFG Registers. An 0x08000000 zu flashen/lesen ist aber der
> sichere Weg, weil der Flash dort immer zu finden ist.
>

Jo. Der wichtige Teil zum Verständnis ist hier, dass der Cortex beim 
Booten seinen initialen SP und PC (Vektoren 0 und 1) IMMER von Adressen 
0 bzw. 4 holt, das ist vom Cortex Kern so vorgegeben und kann nicht von 
Chipherstellern geändert werden!

Was ein Chip aber machen kann, ist den Adressbereich 0 umzuspiegeln, wie 
Dr. Sommer schrieb. Auf STM32F4xxx Prozessoren kann z.B. 0 == 0x800_0000 
(internes Flash) oder 0 == 0x1fff_0000 (interner Bootloader) oder sogar 
0 == 0x2000_0000 (internes SRAM) sein. Damit kann das Booten von 
variablen Speicherbereichen erfolgen.

Dass "fast Alle" Cortex Ms 0x800_0000 als physikalische Flashadresse 
nutzen, scheint mir aber etwas aus dem Fenster gelehnt. Es sind nicht 
Wenige, aber z.B. der NXP Kinetis FRDM64K (M4) hat an 0x800_0000 einen 
Alias für den FlexBus (externer Speicher) und den Flash hardcodiert auf 
0, und der Atmel SAMV71 (Cortex M7) addressiert das interne Flash über 
0x40_0000. Die NXP LPC18xx (M3) Serie macht es noch Anders, weil es dort 
gar kein internes Flash gibt, nur einen internen Bootloader, der den 
Adressbereich 0 nach dem Booten vom Bootloader auf externe Flashes (z.B. 
SPIFI auf Adresse 0x1400_0000) abbilden kann. Also da toben sich die ARM 
Licensees schon aus! ;-)