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=---
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
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
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=---
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 !
Ä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=---
@ 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.
>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
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=---
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
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.
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.
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
