.bootloader overlaps section .data

[Ralf R. (voltax)]

Hallo,

- die section .bootloader befindet sich im FLASH
- und die section .data befindet sich im SRAM

dachte ich jedenfalls bis eben, dann hatte ich heute folgende 
Fehlermeldung (AVRStudio4 WinAVR beide aktuell, ATmega168):
ld.exe: section .bootloader [000000c6 -> 00000107] overlaps section 
.data [000000c6 -> 000000c7]

Wie können die beiden Sektionen überhaupt überlappen, wo sie doch in 
verschiedenen Adressräumen liegen? Bin etwas verwirrt jetzt.

Ich habe meinen Code mal zur Ansicht auf ein Minimum zusammengestrichen, 
sodass praktisch nur noch der Fehler drin ist:

#include <stdint.h>
#include <avr/boot.h>
    
//--- Achtung HIER ---
//uint8_t dies_geht;
uint8_t dies_geht_nicht = 0xFF; //ld.exe: section .bootloader 
                                //[000000c6 -> 00000107] overlaps section
                                //.data [000000c6 -> 000000c7]
//--------------------
    
    
void boot_program_page (uint32_t page, uint8_t *buf) BOOTLOADER_SECTION;
        
void boot_program_page (uint32_t page, uint8_t *buf)
{
   boot_spm_busy_wait (); //--- dummy ---
}


int main(void)
{
   uint8_t buf [SPM_PAGESIZE];   
   boot_program_page (0, buf);   
   return 0;
}

was ist hier falsch?

Grüße Ralf

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

Wie sieht denn das Linkerkommando aus?  Ist das Makefile mit AVR Studio
erzeugt worden?  Ggf. mal mit Mfile probieren.

[Ralf R. (voltax)]

Hallo Jörg,

das Makefile ist von AVR Studio hergestellt worden, alle 
Projekt-Einstellingen sind auf "default". Ich vermute mal, dass man den 
Effekt unter einer anderen AVR Studio Intallation reproduzieren könnte.

Leider kenne ich mich mit C-Tools außerhalb von AVR Strudio noch nicht 
aus, im Moment habe ich noch genug mit C selber zu kämpfen. Ich wäre 
froh, wenn ich mein Programm mit dan AVR Studio Bordmitteln gebuildet 
bekäme. Im Moment probiere ich, alle Initialisierer aus dem Code zu 
entfernen, und globale Variablen stattdessen in einer init-Funktion zu 
initialisieren. Das geht komischerweise ohne dass die Fehlermeldung 
kommt, aber es klappt nicht bei Strings, zB. strcopy (dest, "hallo");

Grüße Ralf

[Werner B. (Gast)]

Hat der Prozessor mehr als 64KB Flash?

Dann verstehe ich das mit den Strings (zumdst Teilweise), weil die dann 
"jenseits" der magischen 64KB Marke liegen und mit gesetztem (wie heisst 
denn das °*&%#~ Bit schon wieder?) Bit zugegriffen werden muss. Kann 
sein dass da der Linker durcheinander kommt.
Lege die Strings mal als static Variablen "außerhalb" der Bootsection an 
und mach dann den strcpy (Oder besser gleich strcpy_P).

//#include <avr/pgmspace.h>

static char hallo[] = "Hallo";
//static char hallo[] PROGMEM = "Hallo";

void boot_program_page (uint32_t page, uint8_t *buf) BOOTLOADER_SECTION;
        
void boot_program_page (uint32_t page, uint8_t *buf)
{
   char my_hallo[6];

   strcpy(my_hallo, hallo);
//   strcpy_P(my_hallo, hallo);
}

Was macht der Linker dann?

[Ralf R. (voltax)]

Hallo,

die Lösung ist, im AVR Studio unter

   Project  Configuration Options  Memory Settings / Add

der Section .bootloader eine feste Adresse zuzuordnen,
also beim ATmega168: Flash .bootloader 0x1C00

"0x1C00" ist zwar laut Atmel-Doku der Defaultwert für die Startadresse 
des Bootloader-Bereichs, aber offenbar muss man dies dem Linker manuell 
mitteilen. Danach funktioniert alles so wie es soll, ohne Überlappung 
beim Linken, und der Bootloader-Code kann auch im Flash schreiben :)

Grüße Ralf

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

Ralf Rosenkranz wrote:

> "0x1C00" ist zwar laut Atmel-Doku der Defaultwert für die Startadresse
> des Bootloader-Bereichs, aber offenbar muss man dies dem Linker manuell
> mitteilen.

Ja klar, woher soll der das auch wissen?  Der Linker hat keine
eingebaute Datenbank über alle AVRs und deren Defaults, ganz davon
zu schweigen, dass du ja per fuses (die der Linker gar nicht kennen
kann, denn sie sind im AVR persistent) auch etwas anderes als den
Default eingestellt haben kannst.

Denk auch dran, dass die Atmel-Doku in 16-bit-Wörtern zählt, die GNU
Tools aber prozessorunabhängig durchweg in 8-bit-Adressen.