seltsame *.hex Datei

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?

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).

Und das elf...

(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).

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.