gcc unterschiedliche (hex) outputs für unterschiedliche Speicherbereiche

[guest (Gast)]

Hi,

gibt es eine möglichkeit, dass meine toolchain mir 2 Hex files 
ausspuckt, das eine, nur für den interenen Speicherbereich (0x08000000 
bis ...) und das andere für den externen Speicher (0x90000000 bis ...)

Hintergrund: Externen Flash muss ich mit eineme anderen Tool 
beschreiben. Wie bekomme ihc das hin?

(bin recht unerfahren im bereich gcc mit irgend welchen "besonderen" 
einstellungen. Bisher hat es meistens immer "einfach so" funktioniert, 
da ich nie groß externen Speicherbereich o.ä. hatte)


IDE ist sw4stm32 (eclipse basierend) für einen STM32

[Jim M. (turboj)]

Müsste man mit (arm-none-eabi-) objcopy hinbekommen, falls die im .elf 
auch ordentlich in 2 verschiedenen Sections angelegt sind.

[Amateur (Gast)]

Ein Hex-File ist eine (fast) simple Text-Datei.
Die kannst Du mit jedem ASCII-Editor zerlegen.

In jeder Zeile ist die zugehörige Adresse angegeben.
Hinter den ersten Block musst Du nur die Abschluss Sequenz schreiben. 
Das ist die letzte Zeile in der Datei.
Da sich die Prüfsumme (letztes Byte in jeder Zeile) auf die jeweils 
aktuelle Zeile bezieht, sollte die auch kein Problem sein. Üblicherweise 
kommen auch keine Blockübergreifenden Zeilen vor.

Allerdings ist es etwas Problematisch, wenn bestimmte Bereiche 
(Adressmäßig) fixiert werden. Dann musst Du die Umschaltsequenzen vor 
dem 2. Block platzieren.
Manchmal befinden sich diese aber auch an genau der richtigen Stelle.

[Jojo S. (Gast)]

so sieht das bei mir im Atollic TS für ein touchgfx Projekt auf dem 
STM32F469 aus, der hat auch ein ext. 16 MB Flash

arm-atollic-eabi-objcopy  -O ihex ${ProjName}.elf target.hex
arm-atollic-eabi-objcopy --remove-section=ExtFlashSection ${ProjName}.elf intflash.elf
arm-atollic-eabi-objcopy  -O ihex --remove-section=ExtFlashSection  ${ProjName}.elf intflash.hex
arm-atollic-eabi-objcopy  -O binary --only-section=ExtFlashSection  ${ProjName}.elf extflash.bin
arm-atollic-eabi-size intflash.elf

Die sections müssen natürlich mit denen im Linkerfile übereinstimmen. 
Für das ExtFlash wird ein .bin erzeugt damit es mit dem STM FlashUtility 
geblitzdingst werden kann.

[Bernd K. (prof7bit)]

Jojo S. schrieb:
> geblitzdingst

Danke! Soeben zum Wortschatz hinzugefügt ;-)

[Jojo S. (Gast)]

> geblitzdingst
>
> Danke! Soeben zum Wortschatz hinzugefügt ;-)

Oha, noch nie 'Men in Black' gesehen?

[Axel S. (a-za-z0-9)]

Amateur schrieb:
> Ein Hex-File ist eine (fast) simple Text-Datei.
> Die kannst Du mit jedem ASCII-Editor zerlegen.

Oder man nimmt ein geeignetes Tool dazu, dann kann man das auch scripten 
(bzw. ins Makefile tun). Für Linux würden sich die srecord Tools 
anbieten, speziell das srec_cat Programm. Das kann (anders als der IMHO 
etwas unglücklich gewählte Name vermuten läßt) nicht nur mit S-Record 
umgehen, sondern mit praktisch allen File-Formaten für ROM/FLASH Daten.

So kann man z.B. 0x0000..0x1000 von in.hex nach out.hex kopieren:

srec_cat in.hex -Intel -Crop 0x0000 0x1000 -Out test.hex -Intel

[Bernd K. (prof7bit)]

Jojo S. schrieb:
> geblitzdingst
> Danke! Soeben zum Wortschatz hinzugefügt ;-)
>
> Oha, noch nie 'Men in Black' gesehen?

Doch, schon zig Mal. Aber die Assoziation mit dem Flashen von 
Mikrocontrollern hat mein Gehirn nie hergestellt. Deshalb hatte ich 
bislang keine Verwendung für den Begriff.