ATmega-Bootloader vom Hauptprogramm aus flashen

Hallo WoSch

1

On devices with boot block, the SPM instruction has the ability to write to the entire

2

Flash memory, but can only be executed from the Boot section. Executing SPM from

3

the Application section will have no effect. On the smaller devices that don’ have a

4

boot block, the SPM instruction can be executed from the entire memory.

Ihr haettet das Updaten also vorsehen müssen, indem ihr von anfang an 
eine kleine Funktion zum "Flashaccess" in die Bootloadersektion (BLS) 
integriert haettet.

Der ueberarbeitete USBaspLoader 
(https://github.com/baerwolf/USBaspLoader) macht soetwas (genannt 
spm-interface) und baut dafuer sogar immer gleich "Updater-Firmware".
Damit ist es auch möglich andere Bootloader auszurüsten. (Siehe 
Beispielboard, welches verschiedene Bootloader gegeneinander auswechseln 
kann: tinyUSBboard - 
http://matrixstorm.com/avr/tinyusbboard/#firmwaresotherbootloader)
(Nicht auf der Seite veroeffentlicht kann ich auch die 
Arduino-Bootloader ausgestattet mit SPMinterface als Auswechselfirmware 
anbieten ;-) )

MfG Stephan

Danke LittleHelper:

LittleHelper schrieb:
> über den Bootloader ein neues Hauptprogramm aufspielen

Um das zu koennen, braucht man ein "spminterface" - ansonsten laeuft der 
Aufruf von SPM (zum Schreiben) einfach ins Leere...

LittleHelper schrieb:
> (Merken, dass
> es der erste Start ist z.B. im EEPROM).

Nein, braucht man nicht - man vergleicht einfach das derzeitig 
installierte Bootimage mit dem aus dem "Updater".
Wenn ungleich, dann "updaten" - ansonsten halten. Ggf. paar LEDs (wenn 
vorhanden) leuchten lassen.

LittleHelper schrieb:
> Wichtig ist, das das Schreiben des Bootloader-Bereichs nicht durch die
> "Boot Loader Lock Bits" gesperrt ist.

full ACK


Hallo nochmal, WoSch

Sollten die Lockbits unveraendert 0x3f sein und dennoch kein 
"spminterface" im BLS sein - so ist dennoch nicht alles verloren.
Wenn alle Kunden derzeit den binaer exakt gleichen Bootloader haben,
kann man ggf. dessen compilierten SPM intelligent durch eine 
Userfirmware "anspringen".
Im Detail muss man aber den Code den die Kunden im Bootloader haben 
genau studieren. Vielleicht moechtest du Ihn hier ja einmal 
bereitstellen.
Heute haette ich noch ein wenig Zeit auch einmal "drueber zu sehen".
Ab morgen dann ersteinmal nicht mehr...

MfG

LittleHelper schrieb:
> Was ist denn ein "spminterface"?

Eine sehr minimale Subroutine im BLS (siehe 
Beitrag "Re: ATmega-Bootloader vom Hauptprogramm aus flashen" und folgend), mit 
der man den SPM Befehl auch aus normaler Firmware heraus nutzen kann.
USBaspLoader nennt dies "spminterface" - ich finde den Namen treffend.

(Abhaengig der von aussen definierten Makros implementiert die folgende 
Headerfile die Subroutine im BLS oder das Interface zur Ansteuerung aus 
der Userfirmware:)
https://github.com/baerwolf/USBaspLoader/blob/testing/firmware/spminterface.h

MfG

Ich konnte nicht umher, einen Hack finden und testen zu wollen:

Anbei der "rohe" Quellcode der Idee.
(
Das Hauptproblem ist, einen Weg zu finden die RWW Sektion wieder zu 
aktivieren, nachdem sie SPM aus der BLS deaktiviert hat.
Da der ganze Firmwarecode in der RWW steht, kann es dort nicht erfolgen, 
da eine Ausführung nach SPM stoppt.

Möglichkeiten zu Abhilfe waren hier:
1) Stack umbiegen um gezielt andere (Teil-)Funktion aus dem Bootloader 
(dissassembly) zur Reaktivierung der RWW beim RET anspringen.
2) Watchdog reset ausloesen lassen beim und flashen ueber mehrere 
"reboots" verteilen.
Methode 2 erscheint flexibler fuer mehr Anwendungsscenarien
)

Falls es jemand einsetzten will/sollte, waere ich um ein kurzes Feedback 
dankbar.

MfG Stephan