kein Sourcelevel Debugging, wenn BOOTRST=0

[Peter (Gast)]

Hallo,

ich habe hier ein kleines Problem mit dem AVR Studio V4.12 SP1 im
Zusammenspiel mit der aktuellen WinAVR (gcc) Umgebung.
Ich möchte für den ATmega128 einen Bootloader entwickeln und das klappt
alles ganz prima bis auf die Tatsache, dass ich mit dem AVR Studio kein
Sourcelevel Debugging betreiben kann, sobald ich den Resetvektor auf
eine Bootresetadresse lege (also weg von der 0x0000).

Um das Problem nachzuvollziehen (ist auch mit dem Simulator möglich;
man braucht also keine Hardware), habe ich ein Minimalprojekt mit
folgender main erstellt:

int main (void)
{
    DDRB    =   (1<<DD5);   /* configure PB5 as output pin */
    PORTB   &=  ~(1<<PB5);  /* switch on LED (low-active) connected to
this pin */

    for (;;); /* endless loop */

    return 0;
}

Das Mapfile sorgt durch folgenden Eintrag dafür, dass der Code an der
richtigen Stelle landet:
# set start-address of text section
# compiler organizes memory as an ..K x 8bit  Array (e.g. 128K x 8bit
with addresses from 0x00000 to 0x1FFFF for ATmega128)
# debugger organizes memory as an ..K x 16bit Array (e.g. 64K x 16bit
with addresses from  0x0000 to  0xFFFF for ATmega128)
# the following setting has to be made with the compiler's
perspective, e.g. 0x1F000 for a boot-reset vector 0xF800
TEXT_START_ADDRESS = 0x1F000
LDFLAGS += -Wl,--section-start=.text=$(TEXT_START_ADDRESS)


Die fuses sind richtig gesetzt (siehe fuses.jpg) und das Programm
funktioniert einwandfrei, was sich im Disassembler leicht
nachvollziehen lässt (siehe AVRstudio_nach_reset.jpg).
Leider stellt der Debugger keinen C- Sourcecode dar bzw. zieht dafür
eine falsche Adresse heran, nämlich die 0x7865 für die main statt der
0xF865 (adresse 0x1F0CA aus mapfile geteilt durch zwei; zur Erläuterung
siehe make-Kommentar oben). Es sieht also so aus, als ob beim
Rekonstruieren der Sourcecode Adressen der Debugger das MSB verschluckt
(die falsche 0x7865 und die richtige 0xF865 unterscheiden sich ja nur
durch das MSB).
Ein Vergrößern/Verkleinern des Bootbereiches (z.B. auf Resetadresse
0xF000 oder 0xFC00) lassen das selbe Verhalten erkennen.

Mache ich was falsch oder bin ich auf einen Bug im AVR Studio
gestoßen?

Ach ja, bevor ich das vergesse: für meinen Zweck kann ich keinen
bestehenden Bootloader einsetzen. Ich muss das Problem also lösen (oder
ohne Sourcelevel Debugging entwickeln).

Vielen Dank,
Peter

[Peter (Gast)]

>> "Das Mapfile sorgt durch folgenden Eintrag dafür, dass der Code an
der richtigen Stelle landet:"

hier muss es natürlich statt "Mapfile" richtig "Makefile" heißen.