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