AVR Studio 6 und Bootloader

[Dirk H. (xplod)]

Hallo zusammen.

Ich habe ein Problem mit meinem ATMega1284:
Ich versuche einen Bootloader zu schreiben, der Daten per I2C entgegen 
nimmt.
Das Programm ist zur Hälfte fertig - Ich kann Daten per I2C senden und 
empfangen. Nun möchte ich aber das Programm in die entsprechende 
Bootloadersektion 0xF000 schreiben.

Ich habe die BOOTRST Fuse gesetzt, und anschließend in der Linker GUI 
die Sektion .text=0xF000 definiert, woraufhin das Studio einen 
Linkeraufruf mit .text=0x1E000 erzeugt.

Wenn ich nun dieses Programm flashe, funktioniert aber leider nichts. 
Beim Laden per JTAG springt er im Assembler an Adresse 0xF306. Es sieht 
aber so aus, als ob das Programm an die Stelle 0xF000 geschrieben worden 
wäre.

Habe ich noch irgendwas vergessen? Hat jemand schon selbst einen 
Bootloader in AVR Studio 6 erstellt?

Gruß,
Dirk

[Thomas (Gast)]

Das sieht etwas nach dem byte-word Problem bei den AVRs aus. 0xF000 
sieht nach einem 8kB Bootloader aus, damit liegt der Bootloader bei 
0x1E000, soweit ich weiß braucht der Linker immer die Adressen im byte 
Format und nicht Word Format, damit musst du im Linker die text sction 
auf 0x1E000 legen.

Wenn du interrupts verwendest musst du diese auch an den Bootloader 
anpassen.

Es kann auch ganz hilfreich sein sich das Hexfile mal mit einem anderen 
Tool anzuschauen, um herauszufinden wo der Code nun wirklich liegt, ich 
verwende dazu immer das Segger J-Flash Tool.

[Dirk H. (xplod)]

Ich habe die Ursache gefunden:
Das Problem lag am MCUCR:

Der Code

temp  = MCUCR;
MCUCR = temp | (1<<IVCE);
MCUCR = temp | (1<<IVSEL);

funktioniert bei mir nie (Weder im AVRSim, noch auf der HW). Auf 
höchster Otimierungsstufe scheint er die geforderten 4 Takte nicht 
einhalten zu können.

MCUCR = (1<<IVCE);
MCUCR = (1<<IVSEL);

Funktioniert dagegen ab Compilerstufe 1!!! Damit funktionieren nun 
endlich die Interruptroutinen...

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

Ich bekomme es mit -Os problemlos hin:

.global setivsel
        .type   setivsel, @function
setivsel:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
        in r24,0x35
        mov r25,r24
        ori r25,lo8(1)
        out 0x35,r25
        ori r24,lo8(2)
        out 0x35,r24
        ret

Das ORI zwischen den beiden OUT-Befehlen dauert ja nur einen Takt, damit
sollte die 4-Takte-Bedingung noch erfüllt sein.

Allerdings gibt es keinen wirklich Grund für diese Veroderung.

[Dirk H. (xplod)]

Ihhh, Assembler :-)

Mein Code sieht nun wie folgt aus:

static void move_interrupt_vector(enum section section_to_use)
{
    uint8_t mcucr_write[2];
    uint8_t current_state = MCUCR;

    switch ( section_to_use )
    {
        case APPLICATION:
            mcucr_write[0] = current_state |  (1<<IVCE); //Enable access
            mcucr_write[1] = current_state & ~(1<<IVSEL); //Set interrupt vector to address 0x0
            break;
        case BOOTLOADER:
            mcucr_write[0] = current_state | (1<<IVCE);  //Enable access
            mcucr_write[1] = current_state | (1<<IVSEL); //Set interrupt vector to address 0xF000
            break;
        default:
            // do nothing
            break;
    }
    MCUCR = mcucr_write[0];  
    MCUCR = mcucr_write[1];  
}

Das Ganze funktioniert sowohl mit -Os, -O1, -O2 und -O3 (laut AVRSim). 
Nur halt -O0 geht nicht...

[Oliver (Gast)]

Dirk Hölscher schrieb:
> Nur halt -O0 geht nicht...

Ohne Optimierung wird der Index von mcucr_write zur Laufzeit 
ausgewertet, das dauert halt länger als 4 Zyklen.

Allerdings ist die Verwendung eines Arrays an dieser Stelle völlig 
überflüssig, vor allem, da der erste Wert für beide Fälle eh immer 
gleich ist.

KISS - keep is simple and stupid

Oliver

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

Dirk Hölscher schrieb:
> Ihhh, Assembler :-)

Das ist der vom Compiler generierte Assemblercode.

Ich versteh' dein Gewürge mit dem Rücklesen des existierenden MCUCR
nicht.  Das Teil hat nach einem Reset einen wohl definierten Wert
(nämlich 0), da kannst du doch einfach drauf schreiben, statt solche
Verrenkungen zu machen.

[Oliver (Gast)]

Oliver schrieb:
> Ohne Optimierung wird der Index von mcucr_write zur Laufzeit
> ausgewertet, das dauert halt länger als 4 Zyklen.

Nachtrag:

Zumindest der gcc 4.3.3, den ich hier auf dem Rechner habe, erzeugt ohne 
Optimierung auch ohne Array solch umständlichen Code, der schafft die 4 
Zyklen ohne Optimierung auch ohne Array nicht.

Oliver

[Dirk H. (xplod)]

Jörg Wunsch schrieb:
> Ich versteh' dein Gewürge mit dem Rücklesen des existierenden MCUCR
> nicht.  Das Teil hat nach einem Reset einen wohl definierten Wert
> (nämlich 0), da kannst du doch einfach drauf schreiben, statt solche
> Verrenkungen zu machen.

Stimmt schon. Ich komme halt aus einer großen Softwareschmiede, und da 
ist es fatal einfach Andererleuts Register zu überschreiben. Also lieber 
chirurgisch nur die Bits anpassen, die ich brauche... Geschmackssache...

Mir ging es aber hauptsächlich um folgende Aussage:

--- Bootloader.c --------------------------
    MCUCR = (1<<IVCE);
0000F084  LDI R24,0x55    Load immediate 
0000F085  LDI R25,0x00    Load immediate 
0000F086  LDI R18,0x01    Load immediate 
0000F087  MOVW R30,R24    Copy register pair 
0000F088  STD Z+0,R18    Store indirect with displacement 
    MCUCR = (1<<IVSEL);
0000F089  LDI R24,0x55    Load immediate 
0000F08A  LDI R25,0x00    Load immediate 
0000F08B  LDI R18,0x02    Load immediate 
0000F08C  MOVW R30,R24    Copy register pair 
0000F08D  STD Z+0,R18    Store indirect with displacement

Danke für den Hinweis mit dem Dissassembler.

Das ist der Code, den der Compiler bei -O0 aus den beiden MCUCR = 
Anweisungen macht. Wie man sieht, werden daraus pro Aufruf je 5 
Anweisungen, was das Nicht-Funktionieren erklärt.

Kann es sein, dass er garnicht auf das MCUCR Register 0x35 zugreift? Ich 
kenne mich in Assembler leider nur sehr schlecht aus...

[Oliver (Gast)]

Dirk H. schrieb:
> Kann es sein, dass er garnicht auf das MCUCR Register 0x35 zugreift? Ich
> kenne mich in Assembler leider nur sehr schlecht aus...

Doch, tut er. Nur hat das Register beim Zugriff per ld die Adresse 0x55.
Der Optimierer nutzt dann den out-Befehl, damit heisst das Register dann 
0x35.

Datenblatt lesen bildet.

Oliver

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

Dirk H. schrieb:

> Ich komme halt aus einer großen Softwareschmiede, und da
> ist es fatal einfach Andererleuts Register zu überschreiben.

Du bist aber hier bei Mikrocontrollern, und bei denen ist oft genug
Effektivität wichtiger als stures Befolgen nicht immer sinnvoller
Richtlinien.

Aktionen wie das Einrichten der Vektortabelle gehören ohnehin mit
zu den ersten Dingen, die man nach einem Reset erledigt, insofern
ist es völlig legitim, dass sie vom Resetzustand des Controllers
ausgehen.

> Das ist der Code, den der Compiler bei -O0 aus den beiden MCUCR =
> Anweisungen macht.

Ja, -O0 eben.  Das will man nicht benutzen, nicht freiwillig.  Ist
wie einen Porsche zu fahren, aber die Handbremse angezogen zu lassen.
Jede Ente fährt dann schneller los.