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
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).
(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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.