hex-file über 8MB groß ?!

[Stefan Seegel (Gast)]

Tach zusammen.

Ich habe heut mal wieder ein Projekt ausgegraben an dem ich schon seit
einigen Monaten nicht mehr gearbeitet habe (Software für meine
Heizungssteuerung). Beim Flashen (Fehlermeldung) ist mir aufgefallen,
dass die hex-Datei (binary format) über 8MB groß ist. Bei einem Blick
in die hex Datei mit einem HexEditor konnte ich feststellen dass
offenbar am Anfang der Datei die richtigen Daten stehen, und danach
(nach ca. 13kB) nur noch 0x00 drin steht. Zuerst dachte ich dass es
irgendwie den avr.objcopy zersemmelt hat, aber eine Neuinstallation von
WinAVR (neuste Version) brauchte auch nichts, ausserdem tritt das
Problem nur bei diesem einen Projekt auf. Noch etwas ist mir
aufgefallen: Erzeuge ich die hex-Datei im ihex Format und öffne selbige
mit Ponyprog, wird die Dateinicht als ihex interpretiert, sprich die
eigentlichen Flashdaten sehen aus wie der Inhalt der ihex Datei. Öffne
ich andere (ihex) hex-Dateien interpretiert das Ponyprog immer
automatisch.

Hat jemand eine Idee ?

Gruß
Stefan

Hier noch die Ausgabe von AVRSIZE:

Size after:
heizctrl.elf  :
section            size      addr
.text             13226         0
.data                42   8388704
.bss                280   8388746
.noinit               0   8389026
.eeprom              14   8454144
.stab               876         0
.stabstr            132         0
.debug_aranges      300         0
.debug_pubnames    2579         0
.debug_info       13754         0
.debug_abbrev      3737         0
.debug_line       10258         0
.debug_str         3747         0
.eepom                1   8389026
.debug_ranges        12     13226
Total             48958

[Μαtthias W. (matthias)]

Hi

die Ausgabe von avr-size sieht eigentlich gut aus. Wie sieht denn dein
Aufruf von avr-objcopy aus der die HEX-Datei erstellt?

Matthias

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

Hat neulich schon jemand berichtet, scheint ein Bug in
den GNU binutils zu sein -- vielleicht getriggert durch die
DWARF-2-Debuginformationen.  Bislang ist noch kein Muster
bekannt, mit dem das reproduzierbar erfolgt, daher ist es
wohl nicht einfach, einen gescheiten Bugreport für die
binutils zu schreiben.

Musst du denn unbedingt binary ausgeben?  ihex und srec scheinen
das Problem ja nicht zu haben.

[Stefan Seegel (Gast)]

Moin,

nein, ich muss nicht unbedingt binary ausgeben (zumindest nicht bei
diesem Projekt, ein anderes hat einen einen MMC-Bootloader, da muss es
binary sein). Aber selbst im ihex-File stimmt was nicht, wie in meinem
ersten Post schon angedeutet: PonyProg interpretiert die Datei nicht
als  ihex, sondern tut so als ob in der Datei bin-Daten drin wären, die
dann natürlich viel zu groß und vor allem sinnentleert sind.
Auch AVRISP im AvrStudio meckert (bei ihex und binary), dass die Datei
zu groß ist. Ich sehe also im Moment keine Möglichkeit mein Compilat in
den AVR zu bekommen, was gerade relativ wichtig wäre (betrifft die
automatische Umschaltung auf Ölbrenner wenn der Holzvergaser leer
ist).
Ich werd mal schaun ob's was bringt mit anderen Debug-Informationen zu
kompilieren.

Gruß
Stefan

[Μαtthias W. (matthias)]

Hi

poste doch einfach mal das .elf und das Makefile. Dann können anderen
auch mal prüfen.

Matthias

[Stefan Seegel (Gast)]

So, ich noch mal hier. Hier kommt zunächst das Makefile, das hat mir
AVRStudio mit GCC-Plugin zusammengebaut (aber auch gleiches Ergebniss
wie makefile von MFile)

[Stefan Seegel (Gast)]

...und hier die elf-Datei...

[Stefan Seegel (Gast)]

...und hier noch das "kaputte" Hex file im ihex-Format. Im Binary
Format wollte ich's hier nicht einspielen, sind ja über 8 MB !

Ach ja, das -gdwarf hab ich bei den c-flags rausgenommen, hat aber
keinen Unterschied gemacht...

Stefan

[peter dannegger (Gast)]

3. Zeile von hinten ist ein extended address record (04), der auf die
Adresse 0x00800000 plaziert.

Diesen Recordtyp kennt auch kaum ein Programmer, da er nur für Adressen
>24 Bit benötigt wird, also für Chips >16MB.

Vermutlich versucht dort jemand die Fuse-Settings abzulegen und hat
einen Spezialprogrammer, der den Record 04 dahingehend interpretiert.

Ich kenne mich mit Makefiles nicht aus, da muß also ein anderer
nachsehen, wo diese Schweinerei passiert.


Peter

[Μαtthias W. (matthias)]

Hi

versuch mal

avr-objcopy -O binary -R .eeprom -R .eepom heizung.elf heizung.bin

Irgendwo in deinem Source wird eine Variable die ins EEPROM sollte
(section eeprom) in .eepom (man beachte das fehlende 'r') verlagert
und diese Section wird dann von avr-objcopy natürlich mit ausgegeben.

Durchsuch deinen Source also mal nach ".eepom" und du solltest das
Problem finden.

Matthias

[Stefan Seegel (Gast)]

TREFFER!

Matthias, du bist der Gott :

unsigned char eoel_mode _attribute_ ((section (".eepom"))) = 2;

Da war der Hund begraben... schnell ein 'r' eingebaut und alles ist
wieder gut. So, nun aber schnell in den Keller und das update
einspielen, der Winter will einfach nicht gehen...

1000 Dank,
Stefan

[Μαtthias W. (matthias)]

Hi

Danke, aber das ist dann wirklich zu viel der Ehre ;-)
Ich war nur der schnellste.

Matthias

[.... (Gast)]

Puh, hier riechts nach Eigenlob...

[Stefan Seegel (Gast)]

hat er ja auch verdient ;-)