Startseite > Messen + Testen > Sensorik > OTA-Schnittstellen für µC-Apps

Design-Praxis / Embedded Software

OTA-Schnittstellen für µC-Apps

17. Dezember 2018, 13:17 Uhr | Benjamin Bucklin Brown, Analog Devices

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Der Second-Stage Bootloader (SSBL)

Die Boot-Reihenfolge verstehen

Beim primären Bootloader handelt es sich um eine Software-Applikation, welche sich dauerhaft im ROM des Mikrocontrollers befindet. Der Speicherbereich des primären Bootloaders wird Infobereich (Info Space) genannt und ist manchmal den Anwendern unzugänglich. Diese Applikation wird bei jedem Rücksetzen ausgeführt, beinhaltet im Allgemeinen einige wichtige Hardware-Initialisierungen und kann Anwender-Software in den Speicher laden.

Falls der Mikrocontroller jedoch nichtflüchtigen Speicher auf dem Chip integriert, beispielsweise Flash Memory, muss der Bootloader keinen Ladevorgang vornehmen und überträgt lediglich Steuerinformationen zum Programm im Flash-Speicher. Falls der primäre Bootloader OTA-Updates nicht unterstützt, ist ein Second-Stage Bootloader nötig.

Jobangebote+ passend zum Thema

Ingenieur/Elektroingenieur/Elektrotechniker als Field Application Engineer

GEYER Electronic GmbH, Planegg

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Genau wie der primäre Bootloader läuft der SSBL bei jedem Rücksetzen, implementiert aber einen Teil des OTA-Update-Prozesses. Die Boot-Reihenfolge zeigt Bild 3. Im weiteren wird die Notwendigkeit des SSBLs beschrieben und welche Kompromisse für die Entwicklung damit einhergehen.

Nie ohne SSBL!

Konzeptionell mag es einfacher erscheinen, auf den SSBL zu verzichten und den gesamten OTA-Update-Funktionsumfang in der Anwenderapplikation unterzubringen. Damit wären ein vorhandenes Software-Framework, Betriebssystem und Device-Treiber für den OTA-Prozess einsetzbar. Das Speicherabbild und die Bootfolge eines solchen Systems zeigt Bild 4.

Applikation A bezeichnet die Originalapplikation auf dem Mikrocontroller.
Sie enthält die zur OTA-Update-Funktion gehörende Software, die Applikation B auf Serveranforderung herunterlädt.

Nach dem Download und der Überprüfung von Applikation B überträgt Applikation A Steuerinformationen zu Applikation B, indem sie einen Verzweigungsbefehl (Branch Instruction) zum Rücksetz-Handler von Applikation B ausführt. Der Rücksetz-Handler ist kurzer Code-Abschnitt, der den Eintrittspunkt (Entry Point) der Software-Applikation nach dem Rücksetzen bedeutet. In diesem Fall wird das Rücksetzen durch Ausführen einer Verzweigung imitiert, was einem Funktionsaufruf (Function Call) entspricht.

Dieser Ansatz birgt zwei größere Probleme:

Viele Embedded-Software-Applikationen nutzen ein Echtzeit-Betriebssystem (RTOS), welches erlaubt, die Software in gleichzeitig ablaufende Aufgaben zu teilen, wobei jede Aufgabe unterschiedliche Verantwortlichkeit im System trägt. Zum Beispiel kann die Applikation in Bild 1 RTOS-Aufgaben wie Auslesen des Sensors, Anwendung eines Algorithmus auf die Sensordaten und Schnittstelle zum Funksystem haben. Das RTOS selbst ist immer aktiv und verantwortlich für das Umschalten zwischen diesen Aufgaben, basierend auf asynchronen Ereignissen oder spezifischen zeitabhängigen Verzögerungen. Daher ist es nicht sicher, von einer RTOS-Aufgabe zu einem neuen Programm zu verzweigen, weil andere Aufgaben noch immer im Hintergrund ablaufen. Der einzige sichere Weg, um ein Programm mit einem RTOS zu beenden, besteht im Rücksetzen.
Ausgehend von Bild 4 bestünde eine Lösung der obigen Problematik darin, den primären Bootloader-Zweig an Applikation B statt an Applikation A zu führen. Allerdings läuft bei manchen Mikrocontrollern auf dem primären Bootloader stets das Programm, bei welchem sich die Interrupt-Vektortabelle (IVT), an Adresse NULL befindet. Dies bedeutet, dass irgendeine Form von IVT-Verlagerung notwendig ist, um eine Reset-Map zu Applikation B zu haben. Falls das System während der IVT-Verlagerung ausgeschaltet wird, könnte es dauerhaften Schaden nehmen.

Diese Probleme lassen sich mit einem fest der Adresse NULL zugeordneten SSBL vermindern (Bild 3). Da der SSBL nicht echtzeitfähig ist, kann er sicher zu einer neuen Applikation verzweigen. Es gibt keinerlei Bedenken, dass ein Abschalten des Systems dieses in einen kritischen Zustand überführt, da die IVT des SSBL an Adresse NULL nie verlagert wird.