Forum: Compiler & IDEs seltsame *.hex Datei


von Tobi (Gast)


Lesenswert?

Hi!

Ich arbeite an einem ATMEGA32 (der hat ja 32kB Flash). Die vom GCC
ausgespuckte *.hex Datei enthält aber extended Frames (also >64KB)
Hier die letzten Zeilen der Datei:

:107FE0007095809590959B01AC01BD01CF010895DE   -- "noch normal"
:027FF000FFCFC1
:0200000400807A                               -- Extended Frame
:100060000000000000000000000000000000000090
:100070000000000000000000000000000000000080
:0200800000007E
:100090000000000000000000000000000000000060
:0E00A000000000000000000000000000000052
:040000030000700089
:00000001FF

Es funktioniert alles, aber wie ist das zu interpretieren? Ist das der
EEPROM-Bereich? (Kann aber eigentlich gar nicht sein, da ich diesen gar
nicht benutze.) Oder soll damit das SRAM auf 0 gesetzt werden?
Vielleicht kann einer von euch mir da helfen.

Grüsse Tobi

von Jörg Wunsch (Gast)


Lesenswert?

Ich spreche leider nicht fließend iHex.

Kannst du eventuell mal die ELF-Datei, aus der das produziert worden
ist, irgendwo (am besten via URL) verfügbar machen sowie das
avr-objcopy-Kommando, das zu dieser Datei geführt hat?

von Tobi (Gast)


Angehängte Dateien:

Lesenswert?

Hi Jörg,

Zur Info (ales in hexadezimaler Form):

:10246200464C5549442050524F46494C4500464C33
|| |   | |                               CC->Checksum
|| |   | DD->Data
|| |   TT->Record Type
|| AAAA->Address
|LL->Record Length
:->Colon

0200000400807A  -- extended frame
TT = 04 (extended frame), Address=0(immer so bei Typ 4)
Data= 0x0080

Der Adressbereich wird auf 32 Bit aufgeweitet, alle folgenden Frames
müssen hier die Adresse "0x0080" (aus Data) um 16 nach links
geschoben voranstellen:

also wird mit

:100060000000000000000000000000000000000090

(Adresse 0x0060 wird zu nun zu 0x00800060)

an die Addresse 0x00800060 (wäre ja SRAM im ATMEGA) 16 Nullen
geschrieben.
Das geht aber meiner Meinung nach gar nicht. Denn wie soll ein
Flash-Brennkommando Zugriff aufs SRAM haben?

Kanns leider nicht via URL, deshalb im Anhang.
Kompiliert hab ich das mit einem Makefile (von mfile generiert und
abgeändert).

von Tobi (Gast)


Angehängte Dateien:

Lesenswert?

Und das elf...

von Jörg Wunsch (Gast)


Lesenswert?

(Eine einzige .tar.gz oder .zip-Datei wäre übrigens sinnvoller
gewesen.)

Tja, das Problem rührt aus deinen etwas unorthodoxen sections namens
.Interface und .Bootsektorram her.  Da das avr-objcopy-Kommando nur
gesagt bekommt, dass es die .eeprom-section nicht mit kopieren soll
(-R .eeprom), kopiert es alles andere.  Durch irgendeine Mimik, die
ich gerade nicht durchschaue, wird dabei .data automatisch an .text
hintendrangehängt.  (Ich glaube, dafür gibt es einen Hack innerhalb
von objcopy selbst.)  Damit bekommt der ROM die Initialwerte für
initialsierte RAM-Variablen mit auf den Weg.  Der Startup-Code weiß
das dann, und belegt den RAM damit vor.

Für deine selbsterfundenen RAM-sections passiert das aber nicht,
sodass diese mit ihren originalen Adressen in die Ausgabe wandern.
Das ist sicher nicht das, was du willst. ;-)

Ich würde an deiner Stelle auf initialisierte Variablen im Bootloader
entweder komplett verzichten oder aber den Bootloader als
eigenständige Applikation schreiben, die völlig unabhängig von der
Hauptapplikation ist (und damit ihre Variablen im RAM mit der
Hauptapplikation überlagert).

von Tobi (Gast)


Lesenswert?

Vielen Dank!

>Für deine selbsterfundenen RAM-sections passiert das aber nicht,
>sodass diese mit ihren originalen Adressen in die Ausgabe wandern.
>Das ist sicher nicht das, was du willst. ;-)

Genau!

Habs mit

@$(OBJCOPY) -O $(FORMAT) -R .eeprom -R .Interface -R .Bootsektorram $<
$@

aber hingekriegt! Guter Hinweis!

Wie gesagt, das ganze hat funktioniert, mir kam das nur spanisch vor.

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.