[ATmega64] Boot Loader und Applikation + gemeinsame globale Variable

[jola (Gast)]

Hallo,

ich habe folgende Anforderungen:
1. Firmware Update über UART
2. Applikation muss im Normabetrieb unverzüglich aufstartten
3. Keine Interaktion mit dem Gerät bis auf UART

Idee/Lösung:
1. Boot Loader (kein Problem)
2. Boot Loader nicht über irgendeine magic number über UART + timeout 
antriggern sondern anders.


Also dachte ich an eine globale Variable die ein FW-Update anzeigt. 
Diese wird sowohl in der Applikation als auch im Boot Loader genutzt. 
Damit muss sie natürlich in der noinit Sektion abgelegt werden, 
allerdings an einer fixen Adresse.

uint8_t fw_update __attribute__ ((section (".noinit")));

int boot_loader(void)
{
   uint8_t reset_source; 
   
   reset_source = MCUCSR;
   MCUCSR = 0;
   
   /* falls watchdog reset und FW-Upate gewünscht */
   if ((reset_source & (1<<WDRF))
         && (TRUE == fw_update))
   {
      /* FW-Update ausführen */
   }
   else
   {
      /* Sofort zur Applikation springen */
   }
}

uint8_t fw_update __attribute__ ((section (".noinit")));

int application_main(void)
{
   fw_update = FALSE; 

   /* ... */
   
   if ("FW-Update starten")
   {
      fw_update = TRUE; 
      
      wdt_enable(WDTO_2S);
      wdt_reset();
   }
}

Meiner Meinung nach muss ich sicherstellen, dass beides mal die 
fw_update Variable an der selben Stelle im SRAM abgelegt wird. Denn in 
der Applikation gibt es noch mehr globale Variablen an anderen Stellen.

Wie kann ich das tun?

Oder wie kann ich mir eine einge Sektion erstellen an einer definierten 
Stelle die ebenfalls wie ".noinit" nicht initialisiert wird?

uint8_t fw_update __attribute__ ((section (".fwupdate")));

...

avr-gcc -mmcu=atmega64 -Wl,-Map=avr_gcc_test.map -Wl,-section-start=fwupdate=0x800100 avr_gcc_test.o -o avr_gcc_test.elf

Was gibt es noch für Möglichkeiten?

Leider kann ich nicht von außen an einem Pin wackeln um das FW Update zu 
triggern. Und zu lange auf ein entsprechendes UART zeichen warten um das 
FW-Update anzuzeigen geht auch nicht. Im Normalfall muss die Applikation 
ruck zuck da sein.



Grüße
jola

[Stefan E. (sternst)]

Warum nimmst du nicht ein Flag im EEPROM?
Erstens hat das (im Gegensatz zum RAM) keinen eher zufälligen Inhalt 
direkt nach einem Power-Up, und zum anderen brauchst du keine weiteren 
Verrenkungen, um im Bootloader und in der Applikation auf die selbe 
Adresse (letztes Byte im EEPROM würde sich z.B. anbieten) zuzugreifen.

[jola (Gast)]

ja das EEPROM habe ich als weitere Lösung im Hinterkopf.

Allerdings fände ich die Realisierung über .noinit "schöner". Man muss 
ja keine EEPROM Zelle verschwenden, wenn es eine andere Lösung über SRAM 
gibt... ...wenn es eine gibt :)

[Stefan E. (sternst)]

jola schrieb:

> Allerdings fände ich die Realisierung über .noinit "schöner".

Sorry, mir erschließt sich diese "Schönheit" nicht.

Was sich mir auch nicht erschließt, ist, wie das dann überhaupt sicher 
funktionieren soll. Flag wird auf "Flashen" gesetzt, der Bootloader 
gestartet, und mitten im Flashen fällt der Strom für eine Stunde aus. 
Nach dem erneuten Power-Up enthält sowohl das Flash, als auch das Flag 
im RAM nur Müll. Welche Entscheidung soll nun der Bootloader auf der 
Basis welcher Informationen treffen?

[Peter D. (peda)]

jola schrieb:
> Und zu lange auf ein entsprechendes UART zeichen warten um das
> FW-Update anzuzeigen geht auch nicht. Im Normalfall muss die Applikation
> ruck zuck da sein.

Ich warte in meinem Bootloader 300ms und finde das in keinster Weise 
störend.
Der Vorteil ist, daß man so immer an den Bootloader kommt, auch wenn die 
Applikation buggy ist.


Peter

[jola (Gast)]

Peter Dannegger schrieb:
> Der Vorteil ist, daß man so immer an den Bootloader kommt, auch wenn die
> Applikation buggy ist.

...hm, das ist natürlich klar. Daran habe ich jetzt wirklich nicht 
gedacht. Der Start des Boot Loaders wäre in meinem Fall von der 
Applikation abhängig und das ist ja genau nicht der Sinn der Sache, 
überzeugt.

Peter Dannegger schrieb:
> Ich warte in meinem Bootloader 300ms und finde das in keinster Weise
> störend

Und wie sieht das über einen FT232 aus? Reichen da auch 300ms um über 
USB das zeitlich noch hinzukriegen?

[Peter D. (peda)]

jola schrieb:
> Und wie sieht das über einen FT232 aus? Reichen da auch 300ms um über
> USB das zeitlich noch hinzukriegen?

Keine Ahnung.
Ich benutze fertige USB-RS232 Umsetzer (Prolific, FTDI) unter XP, damit 
gehts.


Peter

[jola (Gast)]

Peter Dannegger schrieb:
> jola schrieb:
>> Und wie sieht das über einen FT232 aus? Reichen da auch 300ms um über
>> USB das zeitlich noch hinzukriegen?
>
> Keine Ahnung.
> Ich benutze fertige USB-RS232 Umsetzer (Prolific, FTDI) unter XP, damit
> gehts.

FT232/FTDI... also geht es. Die 300ms werd ich dann wohl mal ausmessen.

jola

[Karl H. (kbuchegg)]

Ausserdem ist das nicht sooo kritisch.
Du startest zuerst das Übertragungsprogramm am PC und erst dann wird der 
µC resettet. Wenn der µC anfängt an der USART zu lauschen, ballert der 
PC schon längst sein Anfragebyte über die Serielle imeer wieder und 
wieder raus.