Jump zum Bootloader beim XMEGA

Ich würde es mal so versuchen:

1

void(* jump_to_bootloader)(void) = (void (*)(void))(BOOT_SECTION_START/2+0x1FC/2);

2

EIND = BOOT_SECTION_START>>17;

3

jump_to_bootloader();

Wobei der Offset der Einsprungadresse 0x1FC natürlich von dir angepasst 
werden muss.

Ich hab mich jetzt nicht sehr lange mit deinem Problem beschäftigt, aber 
bei Atmel sieht das anders aus.
http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_EIJMP.html

OUT und STS sind nicht äquivalent!

Johann schrieb:
> :-)
>
> Diese Zeile überfordert mich ein wenig :-)

Funktioniert aber.  Ich habe mal den Einsprungoffset weggenommen
(also Einsprung direkt an den Anfang des Laders) und ein typedef
eingeführt:

1

#include <avr/io.h>

2

3

typedef void (*bldr_t)(void) __attribute__((noreturn));

4

5

int main(void)

6

{

7

  const bldr_t jump_to_bootloader = (bldr_t)(BOOT_SECTION_START/2);

8

  EIND = BOOT_SECTION_START>>17;

9

  jump_to_bootloader();

10

11

  return 0;

12

}

Das macht der Compiler draus:

1

.global main

2

        .type   main, @function

3

main:

4

/* prologue: function */

5

/* frame size = 0 */

6

/* stack size = 0 */

7

.L__stack_usage = 0

8

        ldi r24,lo8(2)

9

        out 0x3c,r24

10

        ldi r30,0

11

        ldi r31,0

12

        eicall

Johann schrieb:

> aber macht der eicall nicht einen Sprung und legt die Rücksprungadresse
> auf den Stack ab

Ja, macht er.

> so das er dann wieder zurückspringt und es dann zu
> Problemen kommt?

Wer ist „er“?  Wer springt denn da wann zurück?  Dein Bootloader?
Warum sollte er?

Allerdings sollte der Bootloader den Stackpointer (re-)initialisieren.

> Kannst Du vielleicht noch etwas zu diesen 2 Zeilen schreiben was diese
> genau machen?

C-Buch, Kapitel über Zeiger?

> typedef void (*bldr_t)(void) __attribute__((noreturn));

Vereinbart einen Datentypen (namens „bldr_t“) für einen
Funktionszeiger, wobei die Funktion keinen Rückgabewert hat (void),
ja nicht einmal überhaupt zurückzukehren gedenkt (attribute noreturn),
und keine Parameter übernimmt ((void)).

> const bldr_t jump_to_bootloader = (bldr_t)(BOOT_SECTION_START/2);

Bildet einen solchen Zeiger per Typecast aus einer Konstante.

Johann schrieb:
> das ist dann aber schon advance c.

Nö, nur Zeiger bis zu Ende verstanden. ;-)

Allerdings gebe ich gern zu, dass das Abtrennen des Typs in einem
typedef hier wirklich sinnvoll ist.

Dieter Frohnapfel schrieb:
> sollte es nicht reichen, wenn Johann den Offset in sein Konstrukt
> einbaut und auf die word-address (das Teilen durch 2) umstellt -
> (0x40000 + 0x1FC) / 2 = 0x200FE:

Zumindest mit dem AVR-GCC nicht: der hat nur 16 bit breite Zeiger.

> Internal firmware request: The user application can decide to start a
> DFU session. This can be achieved by jumping to a specific address in
> the boot loader firmware.

Setzt aber voraus, dass er einen DFU-Bootloader installiert hat.  Ich
habe aber den Eindruck, dass es sein eigener Bootloader ist.

Johann schrieb:
> Ich verwende eine RS232 Interrupt um die neuen RS232 Flash Daten zu
> empfangen.

IVSEL gesetzt?

Ansonsten kann man einen Bootloader auch gepollt schreiben.

Du solltest bedenken, dass wenn du von der Applikation in den Bootloader 
springst, dass alle Register so bleiben wie sie sind. Also würde ich 
vorher einen Zustand herstellen, der quasi dem Reset entspricht. Also 
alle Interrupts voher deaktivieren, RTC deaktivieren...
Arbeitest du im Bootloader mit Interrupts? Wenn ja musst du den 
ISR-Vektor noch verbiegen, das kannst du über BOOTRST und IVSEL.

Johann schrieb:
> Ich könnte ja einfach aus der Application herraus das BOOTRST Fuse
> verändern anschließnd einen Reset auslösen und alles wäre wunderbar.

Der Sinn einer Fuse ist es aber, nun gerade nicht durch die
Applikation änderbar zu sein.

Nur, weil du gerade deine Software nicht im Griff hast, brauchst du
jetzt nicht die Schuld beim Hardwarehersteller suchen …

Es steht dir ja völlig frei, die Fuse immer zu setzen und bei Bedarf
einfach per Watchdog einen Reset zu veranlassen.  Dann hast du das
Problem halt andersrum, der Bootloader muss dann entscheiden, wann
und wie er die Applikation anspringen will.

Johann schrieb:
> ich habe mal meinen Bootloader angehängt

Sourcecode wäre einfacher zu entziffern …

> Ich dachte die Einsprungadresse ist die Adresse 0x20000?

Ja, ist sie auch.

Johann schrieb:
> Der Programm Counter bleibt bei 0x2021E stehen. Als wenn es eine
> Endlosschleife ist wie bei While(1)

Ist es ja auch, das ist deine while(1)-Schleife aus main().  Was
sollte denn in dieser sonst noch passieren?

Alles, was passiert, muss ja über einen Interrupt passieren.

Am Einsprungpunkt des Codes erfolgt ein Stück Initialisierung,
dann ein Sprung auf Byteadresse 0x4043a:

1

  …

2

  (Hier wird übrigens SP initialisiert)

3

   402a8:       ef ef           ldi     r30, 0xFF       ; 255

4

   402aa:       ed bf           out     0x3d, r30       ; 61

5

   402ac:       ef e5           ldi     r30, 0x5F       ; 95

6

   402ae:       ee bf           out     0x3e, r30       ; 62

7

   402b0:       c0 e0           ldi     r28, 0x00       ; 0

8

   402b2:       d0 e3           ldi     r29, 0x30       ; 48

9

   402b4:       1c 94 1d 02     jmp     0x4043a ;  0x4043a

Dort steht offenbar main():

1

   4043a:       d7 d1           rcall   .+942           ;  0x407ea

2

   4043c:       ff cf           rjmp    .-2             ;  0x4043c

3

   4043e:       ff cf           rjmp    .-2             ;  0x4043e

Die zweite Endlosschleife scheint dein Compiler (welcher auch immer
es ist, hast du uns nicht verraten) nach main() hinzuzufügen, die
erste ist deine eigene.

0x407ea ist die Init-Routine, die dein Compiler auch stur so wie
geschrieben aufdröselt:

1

   407ea:       2a de           rcall   .-940           ;  0x40440

2

   407ec:       39 de           rcall   .-910           ;  0x40460

3

   407ee:       7a de           rcall   .-780           ;  0x404e4

4

   407f0:       45 df           rcall   .-374           ;  0x4067c

5

   407f2:       4b df           rcall   .-362           ;  0x4068a

6

   407f4:       82 df           rcall   .-252           ;  0x406fa

7

   407f6:       a3 df           rcall   .-186           ;  0x4073e

8

   407f8:       78 94           sei

9

   407fa:       08 95           ret

Johann schrieb:
> komme ich nicht in die RS232 Routine vom Booloader.

PMIC-Setup?

Ich müsste mir die Details für dieses Teil jetzt im Datenblatt
durchwälzen.  Das wäre aber potenziell ein Unterschied zwischen dem,
was dir deine Applikation beim Einsprung in den Bootloader hinterlässt
und dem, was du beim Anspringen des Bootloaders per Reset hast.

Ich würde wohl nach möglichster Möglichkeit versuchen, in einem
Bootloader nur minimal an der Hardware herumzufummeln (nur das
wirklich für den Loader nötige) und ohne Interrupts auszukommen. Ob
du nun da in einem while(1) im main() Däumchen drehst oder an der
Stelle den UART-Rx pollst, bleibt sich schließlich gleich.

Jörg Wunsch schrieb:
> PMIC-Setup?

Lass dir doch mal die PMIC-Register dumpen einerseits wenn du die
BOOTRST-Fuse gesetzt hast und andererseits wenn dein Loader von der
Applikation aus angesprungen worden ist.

Johann schrieb:
> Demnach muss der XMEGA vollständig initialisiert sein.

Ja klar, du bist ja schließlich in deiner while(1)-Schleife in main().

Wie ich schon schrob: guck dir den Interruptcontroller an.

Solange du in einer ISR bist sind globale Interrupts aus (ISRs sind 
normalerweise nicht unterbrechbar)

Und wenn du aus der ISR einen Sprung machst, denkt der Controller das du 
immer noch in der ISR bist.
Der ASM-Befehl RETI aktiviert beim Beenden der ISR wieder die globalen 
Interrupts.

Ich kenne mich mit den XMegas nicht aus, die haben ja so ein tolles 
Eventsystem.


Bei den normalen Megas, sollte eigentlich ein sei() reichen, was du 
vermutlich in deinem Bootloadercode auch tust.

Vor deinem Sprung sollte man alle ISRs deaktivieren.


Und noch was, eigentlich ist die elegante Methode einen Reset 
auszulösen, den Watchdog ablaufen zu lassen. Danach wird der Controller 
auch Hardwareseitig komplett neu initialisiert.
Du hast ja geschrieben das bei einem Reset bei dir zuerst der Bootloader 
startet.

Christian K. schrieb:
> Ich kenne mich mit den XMegas nicht aus, die haben ja so ein tolles
> Eventsystem.

Insbesondere haben sie einen Interruptcontroller (wies ich nicht
oben ausdrücklich darauf hin?), und der denkt natürlich auch, dass
die zugehörige ISR nach wie vor in Bearbeitung ist …

Johann schrieb:
> Ich bin davon ausgegangen das mein Resetvektor im Bootloader alles neu
> Initialisiert.

Beitrag "Re: Jump zum Bootloader beim XMEGA"

Christian K. schrieb:
> Solange du in einer ISR bist sind globale Interrupts aus (ISRs sind
> normalerweise nicht unterbrechbar)

Nicht beim XMEGA. Dort kann ein höher priorisierter Interrupt einen 
niedriger priorisierten unterbrechen. Aber Du hast schon Recht, 
irgendwann muss schon ein passendes reti kommen, um die noch laufende 
ISR abzuschließen.

Ein RETI macht das gleiche wie ein RET, oberstes Element des Stacks in 
den PC laden und zusätzlich das I-Flag im SREG setzen.

Ich konnte jetzt keine Informationen finden ob das RETI bei einem XMega 
mehr macht.

Da ein XMega ein Interrupt Controller hat, würd ich dir mal raten das 
Disassembly einer ISR anzuschauen, um zu checken ob am Ende der ISR vor 
dem RETI noch irgendwelche anderen Registerbits verändert werden.

Johann schrieb:
> Aber über welchen Befehl kann ich dann das RETI löschen so das mein
> Bootloader nicht mehr denkt das er noch im Interrupt ist?

Warum zum Geier™ tust du nicht endlich mal, was ich dir die ganze
Zeit lang predige, und guckst dir das Kapitel zum Interruptcontroller
im Datenblatt an?  Ich mein', ich klapp' das Ding auf, und es guckt
mich ein Statusregister an, bei dem sowas steht:

1

Bit 0 ­ LOLVLEX: Low-level Interrupt Executing

2

This flag is set when a low-level interrupt is executing or when the interrupt handler has been interrupted by an

3

interrupt from higher level or an NMI. The flag will be cleared when returning (RETI) from the interrupt handler.

Gut zu wissen das ein RETI bei einem XMega mehr macht.

Im Offiziellen "AVR Instruction Set Manual" und im Kapitel Instruction 
Set Summary eines XMegas-Datenblatts gibt es keinen Verweis darauf.

@Johann
Jetzt hab ich mir mal das Datenblatt vom Xmega A3U geladen, aber ich 
find die zitierte Passage nicht. Auch die Volltextsuche bring nichts.


EDIT:
Atmel hat bei den Datenblättern der XMegas outgesourced.
Im Xmega AU hab ich es gefunden.

spess53 schrieb:
> Die interessanten Sachen stehen im entsprechenden Manual:

Ja, diese doppelten Datenblätter sind Scheibenkleister.  Wenn sie
wenigstens im per-device datasheet dann die unnötigen Kapitel-stubs
gleich weggelassen hätten, aber so erwecken die Dinger immer noch
den Eindruck, als würden sie alles abdecken, obwohl man in Wirklichkeit
darin nur einige ganz wenige Details findet, während der große Rest im
Familien-Datenblatt steht.

Aber wenn man irgendwie ernsthaft was mit einem Xmega macht, sollte
man das eigentlich kennen.

Christian K. schrieb:
> Im Offiziellen "AVR Instruction Set Manual" und im Kapitel Instruction
> Set Summary eines XMegas-Datenblatts gibt es keinen Verweis darauf.

Es gibt auch keinen Hinweis drauf, dass bspw. ein OUT auf ein
bestimmtes Portregister ein Pin toggeln kann oder ein Interruptflag
löschen.

Spätestens, wenn man aber mal irgendwie versucht nachzudenken, wie sie
die Interruptpriorisierung gelöst haben können, wird einem klar, dass
der Interruptcontroller auf irgendeine Weise wissen muss, dass gerade
eine ISR in Bearbeitung ist, denn nur so kann er verhindern, dass bei
global zugelassenen Interrupts ein Interrupt gleicher oder niederer
Priorität die aktuelle ISR unterbricht.

Hallo Leute,

ich versuche im Moment den Bootloader mit der Version 1.04 auf meinem 
AtxMega63A3U zum Laufen zu bekommen.

Ich möchte den bootloader aus meiner Applikation starten.
Die Abfrage des IOs zum Starten des Bootloaders habe ich ausgebaut.
So dass dieser starten sollte. Kompiliert habe ich mit IAR.

Die Fusebits habe ich auf die Applikaiton gestellt.

In meiner Applikation benutze ich die USB-Schnittstelle um mit dem PC zu 
kommunizieren.

Mir fehlt jetzt noch der Jump aus der Applikation in den Bootloader.
Ich habe zwar schon einiges hier gelesen aber ich kriege es nicht hin.

Hat jemand dies schon zuverlässig lösen können?

Danke.

Gruß,
Georg.

Georg X. schrieb:
> Hat jemand dies schon zuverlässig lösen können?

Bitte öffne einen eigenen Thread, dein Problem hat nur den Namen
gemeinsam mit dem Problem, welches in diesem Thread hier behandelt
worden ist (verklemmter Interruptcontroller).

Ach, und beschreibe dein Problem umfassend, insbesondere was du
im Moment tust.

Georg X. schrieb:
> Mir fehlt jetzt noch der Jump aus der Applikation in den Bootloader.
Unabhängig vom Device sollte das hier funzen:

1

void(* jump_to_bootloader)(void) = (void (*)(void))(BOOT_SECTION_START/2+0x1FC/2);

2

jump_to_bootloader();