Bootloader .text Probleme (Strings)

[Steve (Gast)]

Hallo,

ich befolge gerade das Tutorial zu Bootloadern in C.

http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung

Dazu habe ich auch (bei mir in eclipse) einen Linker Parameter gesetzt 
(-Ttext=0x1800), um den bootloader an die richtige Stelle im Flash zu 
verschieben.

Das Programm an sich funktioniert, nur kommen auf der Seriellen 
Schnittstelle nur hyroglyphen an! Also anscheinend wurden die Strings 
"Bootloader gestartet" etc. nicht mit dem Programm verschoben.
Also das Programm reagiert richtig auf Eingaben und zeigt mir zwischen 
den hyroglyphen auch mein eingegebenes Zeichen an.

Wenn ich allerdings den linker-switch weglasse, funktioniert alles wie 
gewollt. Ausgabe: "Du hast folgendes Zeichen gesendet: m"

Allerdings steht er dann nicht an der richtigen stelle ;)

Was mache ich falsch?

[Steve (Gast)]

Ja, hm. gehe ich richtig in der ANnahme, dass das initialisierte 
Variablen sind un die in .data liegen (wird auch größer wenn ich mehr 
text dazuschreibe, .text allerdings auch)


Muss denn .data nicht verschoben werden?

[Steve (Gast)]

Unlösbar das ganze... ^^ Sobald ich via Linker den Bootloader an seine 
Adresse verschiebe, sind alle "Strings" weg...

    uart_puts("Hallo hier ist der Bootloader\n\r");

resultiert in xy mal dem selben kryptischen Zeichen.

   uart_puts("Du hast folgendes Zeichen gesendet: ");
   uart_putc((unsigned char)c);
   uart_puts("\n\r");

=> viele kryptische Zeichen, dann das eingegebene Zeichen, dann wieder 4 
kryptische


das kryptische ist jedes mal das selbe.

[Thomas E. (thomase)]

Steve schrieb:
> Unlösbar das ganze...
Quatsch. Bei jedem anderen funktioniert das.
Poste deinen Quelltext.

mfg.

[holger (Gast)]

>=> viele kryptische Zeichen, dann das eingegebene Zeichen, dann wieder 4
>kryptische

Dann wird uart_puts() wohl faul sein.

[Karl H. (kbuchegg)]

Welchen µC benutzt du?

> Dazu habe ich auch (bei mir in eclipse) einen Linker Parameter
> gesetzt (-Ttext=0x1800), um den bootloader an die richtige Stelle
> im Flash zu verschieben.

Die ist klar, dass die 0x1800 µC-spezifisch sind?
Wenn du einen anderen µC als den im Tutorial verwendeten Mega88 benutzt, 
dann musst du für deinen µC diesen Wert neu berechnen.

[Steve (Gast)]

Ich hab einen Atmega1280 und hab das 0x1800 durch 0x1E000 ersetzt 
(0xf000) * 2

mein quelltext ist exakt der von der website + peter fleurys lib.

Sobald ich das Prog nicht nach 0x1e000 verschiebe, sondern an 0x0 laufen 
lasse, funktioniert alles.
Im Prinzip funktioniert es ja an 0x1e000 auch (reagiert richtig auf 
zeichen etc.)
Nur die Strings sind halt "weg"

[Karl H. (kbuchegg)]

Oha. Das ist aber eine nicht ganz unwichtige Information!

Mit einer Startadresse von 1E000 bist du über den 64K drüber, die mit 
einem normalen 16 Bit Pointer adressiert werden können, da wird dann 
alles ein wenig unangenehmer. Und ob der Startupcode, der die Strings 
zunächst vom Flash ins SRAM verschieben muss, damit klar kommt und far 
Pointer fürs kopieren verwendet, weiß ich nicht. Es sieht aber so aus, 
als ob er das nicht tun würde.

[Johann L. (gjlayde)]

Karl Heinz Buchegger schrieb:

> Und ob der Startupcode, der die Strings zunächst vom Flash ins
> SRAM verschieben muss, damit klar kommt und far Pointer fürs
> kopieren verwendet, weiß ich nicht.

Ja, tut er.  Zumindest in der aktuellen Compilerversion, siehe
http://gcc.gnu.org/viewcvs/trunk/libgcc/config/avr/lib1funcs.S?revision=191345&view=markup#l1981

[Stefan E. (sternst)]

Johann L. schrieb:
> Karl Heinz Buchegger schrieb:
>
>> Und ob der Startupcode, der die Strings zunächst vom Flash ins
>> SRAM verschieben muss, damit klar kommt und far Pointer fürs
>> kopieren verwendet, weiß ich nicht.
>
> Ja, tut er.  Zumindest in der aktuellen Compilerversion, siehe
> http://gcc.gnu.org/viewcvs/trunk/libgcc/config/avr...

Es ist aber auch mindestens eine Toolchain (die aus AVR-Studio5?) im 
Umlauf, die im Startup-Code fälschlicherweise LPM statt ELPM verwendet.