Hallo, Ich bekomme beim Linken folgenden Fehler: --------------------- avr-gcc (GCC) 3.4.1 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Linking: buskoppler.elf avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=buskoppler.o -std=gnu99 -mint8 -Wp,-M,-MP,-MT,buskoppler.o,-MF,.dep/buskoppler.elf.d buskoppler.o spi.o can.o scheduler.o taster.o relais.o dimmer.o tab.o --output buskoppler.elf -Wl,-Map=buskoppler.map,--cref -lm -lm C:\Programme\WinAVR\bin\..\lib\gcc\avr\3.4.1\..\..\..\..\avr\bin\ld.exe: section .ftext [00000da8 -> 000015a7] overlaps section .data [00000da8 -> 00000da9] make: *** [buskoppler.elf] Error 1 --------------------- Hat jemand eine Ahnung, was da schief läuft? Joline
>section .ftext [00000da8 -> 000015a7]
Section .ftext?
Ich habe diese Section in keinem der standard Linkerscripts gefunden.
Hast Du diese Section selber definiert oder verwendest Du gar ein
eigenes Linkerscript? Vielleicht ist es auch nur ein Makefile-Fehler.
Das Ganze ist ein bestehendes Projekt. Ich wollte nur mal sehen, ob ich
das bei mir auch übersetzen kann.
Im makefile steht u.a.
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref,--script=buskoppler_avr5.x
wobei ich die Datei: buskoppler_avr5.x nicht habe. Also habe ich den
Schalter rauskommentiert.
In einer der Quellen finden sich dann mehrfach folgende Einträge:
const module_parm_typ module_parm[module_anz] _attribute_ ((section
(".ftext"))) = {
...
}
Wahrscheinlich müßte man die Section .data irgendwo anders hinlegen,
oder?
Die Section .data enthält doch standardmäßig einfach alle
Variablen/Konstanten, oder? Und mit Section .ftext legt man einen
gesonderten Datenspeicherbereich an, richtig?
Also die .data Section würde ich nicht verschieben. Ich vermute, daß ".ftext" die Section "text" im "_f_lash" beschreiben soll. Die wird wohl in dem buskoppler_avr5.x definiert sein. Probiere einfach mal, den ganzen Kram auf die PROGMEM-Schiene zu "Portieren".
Ich denke auch, dass das im Flash landen soll. Wie muss man das dann definieren?
Naja, eigentlich ist das recht einfach, Du musst nur
_attribute_ ((section(".ftext")))
durch
PROGMEM
ersetzen. Aber sag mir doch bitte erst mal, wie zum Beispiel auf
'module_parm' zugegriffen wird.
Beispiel:
const module_parm_typ module_parm[module_anz] _attribute_
((section(".ftext"))) = {
wird zu:
[C]
const module_parm_typ module_parm[module_anz] PROGMEM = {
Also vielen Dank erst mal. Das mit PROGMEM hat funktioniert. Aber wie definiert man das, damit das im Flash landet? Hinter module_parm_typ verbirgt sich ein Array mit verschiedenen Werten. Dieses Array wird an verschiedene Funktionen übergeben und die arbeiten dann entsprechend. Man kann über eine Änderung des Parameterfeldes den Ablauf des Programmes beeinflussen. Deshalb wäre es schon notwendig, wenn dieses Feld im Flash liegt.
PROGMEM sorgt dafür, daß Deine Daten im Flash landen ;) siehe auch: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29
Aha. In dem Quellcode wird ja nun eine eigene Section ".ftext" benutzt. Kann es sein, dass man damit einen "speziellen" Speicherbereich im Flash definieren kann, in dem dann die Daten abgelegt werden? Das würde Sinn machen, um später bei einer Umkonfiguration nicht das ganze Programm neu laden zu müssen, sondern nur das Stück Flash zu überschreiben.
Das könnte schon sein, dazu müsste man halt das Linkerscript kennen. Wenn ich schon wüsste (habe mich nicht mehr damit beschäftigt), wie man eigene Sections im Linkerscript definiert, dann hätte ich auch ein Problem weniger.
Also ich hab mich da jetzt tatsächlich mal mit beschäftigt, weil ich das auch für mein externes SRAM gebrauchen kann. Vielleicht testest Du mal das Linkerscript im Anhang (damit müsstest Du eigentlich die ursprünglichen Quellen verwenden können).
Ich habe mal testweise das Linkerscript avr5.x genommen. Aber damit hat es nur funktioniert, wenn ich wenige Parametersätze habe. Mit Deinem Script funktioniert es prima. Jetzt muss ich mir das mal anschauen, was da genau drin steht. Erstmal recht vielen Dank für die schnelle Hilfe. Joline
Ich hatte gar nicht erwähnt, wie sich Dein Flash jetzt aufteilt :\ Das Programmflash habe ich um 8k auf 120k begrenzt. Die Übrigen 8k stehen Dir jetzt für Deine ".ftext"-Section zur Verfügung, d.h. Du kannst 8k Daten in .ftext ablegen. Von Flash-Adresse 0x0 bis 0x1DFFF hat also Dein Programmcode platz, von 0x1E000 bis 0x1FFFF ist Platz für die .ftext-Daten. Dadurch reduziert sich zwar die maximale Programmgröße, aber Du hast Garantiert ab 0x1E000 Daten stehen, die auch nicht vom Programmcode überschrieben werden können. Inwiefern Du das nutzen kannst, um Konfigurationsdaten über ein Programm update hinaus zu retten, kann ich Dir jetzt auch nicht beantworten. Vermutlich musst Du dem Linker irgendwie mitteilen, daß er diese Section einfach nicht mit in das ELF packt. Aber wie?
Ich hab schon gesehen, es gibt eine neue Section 'ftext' ab Adresse 0x1E000 mit 8k Länge. Wenn es ein Programmupdate gibt, macht es nichts, wenn diese Daten überschrieben werden. Die sollen ja vom Programm nur gelesen werden, also muss man da nichts 'retten'. Somit muss man nach einem Update diesen Speicherbereich einfach mit neuen Parameterdaten beschreiben. Ist schon OK.
Ich hatte jetzt an eine Variante wie im MSP430 gedacht: da gibt es zwei Flash-Segmente, die man unabhängig vom Programmcode lesen und schreiben kann. D.h. ich habe zwei Segmente, in denen ich Parameterdaten ablegen kann, ohne sie beim Programm update neu schreiben zu müssen. Das hat beispielsweise dann Sinn, wenn man dort Adressen einzelner Teilnehmer in einem Bus ablegt o.ä.. Stell Dir vor, Du willst nur eine kleinigkeit im Programm ändern, und musst dann 500 Busteilnehmer entweder nur Updaten, oder eben Updaten und auch noch neu Konfigurieren... Na Mahlzeit! Aber wenn es Dir nur um das Segment .ftext geht: das ginge auch mit der PROGMEM-Lösung :-)
Hi Joline, sorry, dass ich Dir noch nicht geantwortet habe. Ich habe Dich nicht vergessen, sondern nur etwas geschoben, weil die Antwort etwas umfangreicher sein muss, um sinnvoll zu sein ... zu ftext: Richtig, dass soll eine Flash-Sektion sein. Ich hatte folgendes Problem: ich wollte eine Sektion, die eine feste Adresse im Flash hat, weil ich nicht nur vom zugehörigen Programm, sondern auch vom Bootloader auf die Variablen in dieser Sektion zugreifen will. Ausserdem möchte ich bei einem Programmupdate nicht meine Parameter mitupdaten müssen, nur weil sie an einer anderen Adresse als bei der Vorversion gelandet sind. Die "normale" Methode eine Flash-Sektion zu definieren, hat leider nicht funktioniert: gcc hat sie zwar korrekt angelegt, aber AVR-Studio4 hat diese Flash-Sektion ignoriert: sie wurde einfach nicht ins Flash geladen. Daraufhin habe ich eine Weile rumprobiert und bin auf die jetzt implementierte Lösung gekommen: Im Linker-Script-File buskoppler_avr5.x wird eine Sub-Sektion in der Sektion text definiert. Da es eine Sub-Sektion (und keine eigenständige Sektion) ist, wird sie von AVR-Studio4 akzeptiert. Das Ganze ist ein Workaround um einen Bug in AVR-Studio4, ob die neueste Version von AVR-Studio4 dieses Problem noch hat, habe ich nicht probiert. (irgendwo hier gab es dazu auch mal einen eigenständigen Thread). Warum das Ganze bei Dir eine Fehlermeldung erzeugt, ist mir allerdings nicht klar. Ausserhalb des Verzeichnisses Buskoppler habe ich keine Änderungen an der WINAVR-Umgebung gemacht.
Nunja:
>wobei ich die Datei: buskoppler_avr5.x nicht habe.
Das dürfte wohl der Grund für die Meldung sein :)
Wie hast Du die Subsection denn an eine feste Adresse bekommen?
oh megapeinlich .... habe es gleich mal angehängt ...
Die feste Adresse habe ich so hinbekommen:
. = ABSOLUTE(0x2F00);
*(.ftext) /* Platz für Daten mit fester Adr. */
Wie gesagt, in Zusammenhang mit AVR-Studio4 ist der Trick, alles in die
.text Sektion zu packen, selbstdefinierte Sektionen akzeptiert das
Programm nicht (ich verwende .elf).
Viele Grüße, Stefan
Thread beobachten
Seitenaufteilung abschaltenBitte 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.