OpenDCC BiDiBOne - Bootloader

    Hier finden sich tiefergehende Informationen zum Bootloader.

Was ist ein Bootloader?

    Der Bootloader ist ein separates Programm, welches neben der eigentlichen Applikation im Speicher des Prozessors liegt. Es dient dazu, einen Firmware-Update der Applikation durchzuführen. D.h. während dieses Vorganges werden nacheinander Speicherbereiche der Applikation gelöscht und mit der neuen Firmware überschrieben. Das bedeutet, dass zuvor die Applikation angehalten werden muß und anschließen neu gestartet wird.

    Das Löschen und neu Schreiben von Programmspeichern ist i.d.R. eine 'kritische' Aktion auf einem Mikrocontroller und darf nur unter ganz bestimmten Randbedingungen erfolgen (Übergabe der Kontrolle an einen extra Speichercontroller, Abschalten der Interrupts, Clockbedingungen, Ausführen des Codes nur bestimmten Speicherbereichen, usw.).

Wie geht BiDiB mit Bootloadern um?

    Die Möglichkeit zum Firmware-Update wird von Knoten über ein Feature angezeigt. Nur wenn dieses Feature vorhanden ist, darf ein BiDiB-Steuerprogramm Befehle für den FW-Update senden.
    Bootloader haben naturgemäß einen minimalen Funktionsumfang (eben nur Firmware-Update) und sind auch oft in ihrem Kommunikationsverhalten eingeschränkt und müssen zudem oft mit nur sehr wenig Speicher auskommen.

    BiDiB nimmt daher besondere Rücksicht: ein Bootloader braucht nur einen stark reduzierten Funktionsumfang zu enthalten, zudem ist für den FW-Update eine direkte 1:1 Quittung vorgesehen, d.h. erst wenn der Bootloader die letzte Anweisung als erfolgreich abgeschlossen meldet, darf eine neue Anweisung geschickt werden.

    Um eine Unabhängigkeit von der Prozessorplattform zu erhalten, wurde als Format der Daten das allgemein verständliche, alte Intel-Hex Format verwendet, welches 1:1 im Klartext übertragen wird.

Besonderheiten beim BiDiBOne

    Die Prozessorplattform des BiDiBOne ist der ATXmega128. hierbei ist folgendes zu beachten:
  • Der Bootloader muß in der sog. Bootarea liegen, nur von dort aus ist ein schreibender Speicherzugriff auf den Flashspeicher des Prozessors möglich.
  • Wenn der Bootloader angesprungen wird, müssen alle Interrupts geschlossen werden, die Interruptvektortabelle muß auf die Bootarea umgestellt werden.
  • Die Offsetpointer des Flashes (RAMZ) müssen auf die Bootarea zeigen.
  • Der Updateprozess geht page-weise. Eine Page ist ein Speicherblock, welcher nur als ganzes geschrieben werden kann. Um also einen Update vorzunehmen, muß man den Block aus den Flash holen, modifizieren und komplett wieder zurückschreiben.
  • Das Vorhandensein des Bootloaders (und damit das Feature FW_UPDATE) wird von der Applikation über einen Binärvergleich des Schreibe-Lese-Codes ermittelt.
  • Die aktuelle Knotenadresse wird in den Flags GPIOR0 und GPIOR1 (invertiert) übergeben. Der Bootloader übernimmt dann die bisherige Kommunikation. Beim Rücksprung aus dem Bootloader wird eine Neuanmeldung durch einen Timeout provoziert.
  • Innerhalb der Bootarea sind keine üblichen (short) progmem-Zugriffe möglich, d.h. alle Konstanten sind über normales C-Programmcode Init zu belegen, nicht mittels const PROGMEM.
  • Sollte der Bootloader allein starten und keine gültige Knotenadresse vor Aufruf vorhanden sein, so versucht er die Anmeldung mit einer Zufalls-ID. Diese generiert er aus den in der Signatur abgelegten Werten zu Produktionsdatum und Waferadresse.

Anpassung auf andere Prozessor-Größen

  • Man muß die sog. Pagefile-Größe beachten. D.h. wie groß ist der jeweilige Block, den der Prozessor mit einem Schreibvorgang beschreiben kann. Das muß entsprechend im Bootloader-Source so eingestellt werden. Und dann muß der Vergleicher (ist Bootloader vorhanden ja/nein) auch das entsprechende Bin-Image kennen.
  • Die Einsprungadresse ist beim Linkvorgang zu definieren.
  • Das Vorhandensein der jeweiligen GPIOR zur Adressübergabe ist abzuprüfen