mikrocontroller.net

Forum: Projekte & Code Kann ein Bootloader sich selbst updaten?


Autor: ---=DIAN=--- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe einen Bootloader der ohne Probleme funktioniert, aber wie kann sich 
dieser Bootloader selbst erneuern, modifizieren oder löschen ? Also 
OHNE externen Programmer ?

Ich benutze die boot_program_page funktion aus der boot.h von winavr um 
den Flash zu programmieren.

Laut Atmel Datenblatt:
"The program code within the Boot Loader section has the capability to 
write into the entire
Flash, including the Boot Loader Memory. The Boot Loader can thus even 
modify itself, and it
can also erase itself from the code if the feature is not needed 
anymore."

Also wenn ich das richtig verstehe, muß ich dann einfach z.B. bei einem 
Mega32 das Hexfile des Bootloaders an die Startadresse schreiben (z.B. 
$7800 für 2048kB Daten) also dann einfach ab Page 240 ($7800 div 128)? 
Überschreibe ich dann nicht den laufenden Bootloader so das dieser dann 
ggf. abstürzt?

MfG ---=DIAN=---

Autor: winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz einfach er lädt eine Hilfsroutine in einen anderen Bereich, ebenso 
den neuen Bootloader und übergibt dann der Hilfsroutine das Zepter diese 
löscht den alten Bootloader und überschreibt dessen Bereich mit dem 
neuen Bootloader. Anschließend übergibt diese Routine das Kommando an 
den neuen Bootloader und dieser löscht den zur Puffferung und für die 
Hilfsroutine benutzten Bereich.

fertig ist das Wunder

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
winne wrote:
> fertig ist das Wunder

Nicht ganz.

Du mußt dann noch beten, daß dabei nicht der Strom ausfällt, die Daten 
alle richtig übertragen wurden und Du keinen Fehler in dem 
Updateprogramm und in dem neuen Bootloader gemacht hast.


Peter

Autor: ---=DIAN=--- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal Danke für die Antworten.

Ich entnehme mal der Antwort das ich also einfach wie gewohnt eine Page 
beschreibe (also in der Bootloader Section) und der µC sich um den Rest 
kümmert.

"Ganz einfach er lädt eine Hilfsroutine in einen anderen Bereich"

Gilt das auch für diesen theoretischen Fall wenn kein oder kaum 
"Bereich" frei ist? Kann ich weiterhin IRQ's anlassen? (diese sind 
natürlich mit IVSEL / IVCE in den Bootbereich verbogen)

Programm: $0000 - $77FF
Bootloader: $7800 - $7FFF

MfG ---=DIAN=---

Autor: NOOB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, schön wärs. Bei einem AVR ist der Bootbereich nicht umsonst als 
Bootberech gekennzeichnet. Sprich, er ist auch da wenn du den "normalen" 
Bereich beschreibst. Wenn du nun aus dem "normalen" Bereich das Flash 
beschreibst wird der "normale" Bereich ausgeblendet. Ergo: wenn es 
funktioniert ist es wirklich ein Wunder !

Autor: ---=DIAN=--- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äh, wenn ich das Datenblatt richtig deute (z.B. Mega16 Page 246/354):

"The Application section can never store any Boot
Loader code since the SPM instruction is disabled when executed from the 
Application section."

Also wenn "normaler" Bereich = Application section dann sollte das mit 
den Flashen gar nicht gehen weil der SPM Befehl nur aus dem 
Bootloaderbereich  ausgeführt werden kann ...?

Habe im Moment leider nur ne "Produktivumgebung" hier sonst hätte ichs 
schonmal getestet.

MfG ---=DIAN=---

Autor: winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ peda

ich setze vorraus, dass man Checksummen beachtet und benutzt, dafür 
sorgt das der strom anbleibt etc. Wer will darf auch beten. ;-) 
Ansonsten funktioniert das auf keinem System zuverlässig, weder im AVR 
noch im PC beim BIOS_UPDATE.


@ NOOB
Auch sollte man selbstverständlich die datasheet studieren um geeignete 
Speichbänke zu wählen und auch die Zugriffe korrekt organisieren. Wenn 
es damit Probleme gibt kan man noch Interruptvektoren und Segmentzeiger 
verbiegen um gewisse Architekturhürden zu überwinden.
Der Prozessor/µC bestimmt die Vorgehensweise. Die Datasheet verraten ob 
und wie es gehen kann.

Autor: winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Gilt das auch für diesen theoretischen Fall wenn kein oder kaum
>"Bereich" frei ist? Kann ich weiterhin IRQ's anlassen? (diese sind
<natürlich mit IVSEL / IVCE in den Bootbereich verbogen)

>Programm: $0000 - $77FF
>Bootloader: $7800 - $7FFF

Laufende Programme sollte man stoppen, interrupts sperren und 
selbstverständlich brauchst du Platz mindestens für die Hilfsroutine,
und irgendwo im System den PUffer für den neuen Loader. Zur Not extern.
Aber das Beste beim Bootloader uptdate wäre ein Chip den man auch leer 
machen kann.
Achja was Peter schon andeute, es ist ein kritischer Prozess der etwas 
mehr Aufmerksamkeit und Sorgfalt erfordert als eine LED blinken zu 
lassen

Autor: ---=DIAN=--- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die ganzen nett gemeinten Hinweise ;-)

Also bevor weitere Fragen dazu entstehen eine kurze Aufklärung was 
bereits_ _vorhanden_ _ist und funktioniert:

- mehrere µC am RS485 Bus im Multimasterbetrieb mit 
Kollisionsvermeidung
- Eigenes Protokoll mit Adressierung, Datenpaketen und CRC16 Prüfung
- Hardwareschaltung zur RS485 "Bus Frei" Erkennung

Der Bootloader benutzt IRQ's (Uart_Receive) und updatet den Flash 
Bereich über den Bus. Das funktioniert bereits zuverlässig und wie 
gewünscht. Das das nicht nur LED Blinken ist habe ich auch schon in 
mehreren Wanderungen mit Laptop und Prog-kabel durch mein Haus festellen 
dürfen ;-)
Auch das Starten des Bootloaders aus dem Hauptprogamm und andersrum 
funzt problemlos.

Mir gings ja nur darum, wenn ich den Flash bequem per PC übern Bus 
updaten kann, warum dann nicht auch den Bootloader ,wenn's lt. 
Datenblatt möglich ist und programmtechnisch notwendig ist. Jedesmal mit 
dem Laptop durchs Haus tigern ist zwar sportlich aber ...

MfG ---=DIAN=---

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
winne wrote:
> Ansonsten funktioniert das auf keinem System zuverlässig, weder im AVR
> noch im PC beim BIOS_UPDATE.

Genau das wollte ich damit ausdrücken.

Besser ist es, man schreibt den Bootloader sorgfältig, dann muß man ihn 
auch nicht mehr ändern.

Oder man schreibt einen Master-Bootloader, der nicht geändert werden 
kann.
Und dieser kann bei Bedarf einen 2.Bootloader aufrufen, der z.B. ein 
bestimmtes Funkprotokoll implementiert.
Dieser schreibt dann auch nicht direkt, sondern ruft API-Funktionen des 
Master auf.


Peter

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also in meinem sat-rx gab es das.

dort muste für eine neuere firmware,
erst extra der bootlader über die serielle schnittstelle neu geschrieben 
werden.

erst dann, war die neue firmware ladbar.

Autor: Gottfried S. (gottfried)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Programm mit Daten für den neuen Bootloader in das Flasch mittels 
alten Bootloader laden, danach starten wie bei einem normalen Update.

Das Programm vergrößert den Bootbereich, wo dann ein kleines Programm 
startet, das vom Programm-Flash (neuer Bootloader) die Daten holt und 
den alten Bootbereich updated.

Danach wird der Bootbereich wieder verkleinert und der neue Bootloader 
gestartet, der das eigentliche Programm dann per Schnittstelle lädt.

Autor: Saga (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Applikation kann den Bootloader nicht aktualisieren. Das kann nur 
der Bootloader selber. Es ist zwar trickreich, aber es geht. Der 
Bootloader muss von Anfang an so designed werden, dass er in zwei 
Sektionen aufgeteilt ist. Genaugenommen sind es 3 Sektionen: Stage 1 - 
ein Umschalter, der zwischen zwei Bootloader switchen kann, eine 
CRC-Prüfung vornimmt und den gültigen Bootloader anwählt, Stage 2A: der 
eigentliche Bootloader, Stage 2B - der Reservebootloader. Richtig 
implementiert darf sogar ein Stromausfall den Updateprozess stören. 
Beachten muss man natürlich, dass die Größe des eigentlichen Bootloaders 
gehörig schrumpft, man immer nur Pages schreiben kann, immer ein 
gültiger Stage2-Bootloader vorhanden sein muss. Dies läuft auf unseren 
(safety-relevanten) Systemen seit Jahren erfolgreich.

Beste Grüße,
Saga

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.