avr-gcc Linker-Error

>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

Aha, danke!
Das ABSOLUTE-Kommando hatte ich noch nicht entdeckt ;)