Atmega - Aus der Applikation in den Bootloader springen

Man kann ohne Reset in den Bootloader springen. Dann müssen aber 
Applikation und Bootloader genau aufeinander abgestimmt sein.

Warum kein Reset? Damit macht man sich vieles einfacher.

Im Bootloader kannst Du aus dem MCUSR auslesen wodurch der Reset 
ausgelöst wurde. Danach kannst Du dann entscheiden was Du für ne Routine 
laufen lassen willst.

Alternativ zum MCUSR kannst Du auch nen externes Signal abfragen, z.B. 
nen Flipflop was Du vorher gesetzt hast oder nen Taster.

Bei einem Projekt habe ich sowas kombiniert mit nem CRC des 
Hauptprogramms. Also der Bootloader prüft ein externes Flag. Wenn das 
an, springt er in den Bootloader-Teil. Außerdem macht er nen CRC des 
Hauptprogramms und vergleicht das mit einem Wert am Ende des 
Hauptprogramms. Wenn das nicht passt springt er auch in den Bootloader. 
Ansonsten geht er ins Hauptprogramm.

So können Fehler beim Flashen des Programms nicht dazu führen daß der 
Bootloader nicht mehr gestartet wird. Ich darf nur keinen Code 
rausgeben, der die korrekte CRC hat, aber nicht mehr in der Lage ist in 
den Bootloader zu springen.

Funktioniert bisher bestens, ca. 500 Stück bei Kunden draußen, mehrere 
Firmware-Updates und kein einziges Teil Ausfall. Obwohl natürlich einige 
während des Flashens den Stecker gezogen haben.

Gerd E. schrieb:
> Bei einem Projekt habe ich sowas kombiniert mit nem CRC des
> Hauptprogramms. Also der Bootloader prüft ein externes Flag. Wenn das
> an, springt er in den Bootloader-Teil. Außerdem macht er nen CRC des
> Hauptprogramms und vergleicht das mit einem Wert am Ende des
> Hauptprogramms. Wenn das nicht passt springt er auch in den Bootloader.
> Ansonsten geht er ins Hauptprogramm.
>
> So können Fehler beim Flashen des Programms nicht dazu führen daß der
> Bootloader nicht mehr gestartet wird. Ich darf nur keinen Code
> rausgeben, der die korrekte CRC hat, aber nicht mehr in der Lage ist in
> den Bootloader zu springen.

Das wäre aber eher eine Aufgabe des Bootloaders. Bei meinen Bootloadern 
achte ich auf zwei Punkte:
- Fehlererkenung, also sowas wie deine CRC, innerhalb des Bootloaders
- Umprogrammieren des FLASH-Speichers auf eine Art & Weise das erst nach 
vollständigem und korrektem programmieren des FLASHs der Bootloader die 
programmierte Anwendung auch scharf macht.

Hallo.

Seh dir mal http://matrixstorm.com/avr/tinyusbboard/ ,  bzw. dessen 
Bootloader USBaspLoader ( 
https://github.com/baerwolf/USBaspLoader/tree/testing ) an.

Im Code wird sowohl eine API unterstuetzt ( 
https://github.com/baerwolf/USBaspLoader/blob/testing/firmware/spminterface.h 
) mit der man den Flash schreibbar machen kann. (Mehr dazu auch im 
Beitrag "Re: [ATMega] Programm aus externem EEprom laden")

Im der derzeitigen "testing"-branch wird zudem auch ein Springen aus der 
Firmware zum Bootloader (ohne Benutzereinwirken) ermoeglicht.
(Seit commit 
https://github.com/baerwolf/USBaspLoader/commit/fdd80449610db4cccc152e17b04cdb51de578a61 
)

MfG

holger schrieb:
>>Deshalb soll er einfach auf einen Befehler
>>hin, in den Bootloader springen.
>
> Und was machst du wenn die Applikation nicht korrekt geflasht wurde?
> Dann hast du keine Möglichkeit mehr in den Bootloader zu springen.

Wenn der Wadchdog aktiviert ist, könnte es einen WDT-Reset geben und man 
landet im Bootloader.

Philipp schrieb:
> Mann könnte jede
> geflashte Page z.b. mit einer Checksumme vergleichen.

Du hast aber nicht genug ram um erst mal alles zu empfangen, zu prüfen 
und dann erst zu flashen. Du musst also direkt flashen was du bekommst 
und erst hinterher prüfen. wenn du einmal angefangen hast was von dem 
neuen code zu flashen, kannst du nicht einfach mittendrin aufhören und 
hoffen daß das teil dann noch sinnvoll startet.

daher mein vorschlag oben mit der crc über das gesamte flash und das 
starten des bootloaders (also empfang neuen programmcodes über der 
serielle schnittstelle, i2c,...) wenn die nicht stimmt. damit kannst du 
immer neu beginnen den programmcode zu flashen, auch wenn du vorher 
mittendrin abgebrochen hast.