Hallo Leute, wir haben ein paar Geräte mit einem Atmega162 "draußen", die unbedingt einen neuen Bootloader bekommen müssen (der alte hat einen Bug) und das Programmieren via Programmer durch unsere Kunden (Gerät öffnen, zerlegen, programmieren usw ...) oder eine Rücksendeorgie der Geräte wäre ein Graus! Eigentlich eine ganz einfach Frage (wenn man die Antwort kennt), aber ist es beim Atmega162 irgendwie möglich, den Bootloader vom Applikationsprogramm neu zu flashen? Ich weiß ich weiß, nach Aktenlage geht das für den Standard-User ja wohl nicht. Aber ich frage jetzt auch nicht den Standard-User ... wir bräuchten "die geheime Sequenz"/den Trick, mit der das Schreiben durch das Anwendungsprogramm in den Bootloaderbereich eben doch möglich ist. Wir würden dann ein Anwendungsprogramm mit einem neuen Bootloader im Rucksack per Fernupdate aufspielen und das könnten dann den Bootloader neu 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
:
Bearbeitet durch User
Das "Fernupdate" läuft über den Bootloader? Dann: über den Bootloader ein neues Hauptprogramm aufspielen, das dann beim ersten Start wiederum den Bootloaderbereich flasht. (Merken, dass es der erste Start ist z.B. im EEPROM). Wichtig ist, das das Schreiben des Bootloader-Bereichs nicht durch die "Boot Loader Lock Bits" gesperrt ist. Falls dem so ist, kommst Du da nicht mehr ohne Hardware-Programmer ran (mein Kenntnisstand).
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
:
Bearbeitet durch User
Stephan B. schrieb: > Um das zu koennen, braucht man ein "spminterface" Was ist denn ein "spminterface"?
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
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.