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
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.