Im zweiten Teil der Bootloader Reihe möchte ich auf das Konzept der BackUp-Firmware eingehen. Dieses wurde bei MEDtech-Ingenieur entwickelt, um die Zuverlässigkeit von Firmware zu erhöhen, welche auf vorinstallierte Bootloader zurückgreift.
Problembeschreibung
Um das zugrundeliegende Problem zu verstehen, stellen wir uns folgendes Szenario vor:
Ein Medizinprodukt setzt sich unter anderem aus zwei Softwaresystemen zusammen. Das eine ist der GUI-Controller, welcher sich z. B. um die Visualisierung von Signalen (EKG, Atemkurve, …) kümmert. Die andere Komponente ist ein Mikrocontroller, welcher sich um die Hardwarespezifische Funktionen (z. B. Powermanagement, Datenerfassung, …) kümmert. Der GUI-Controller kann über WLAN Updates erhalten. Die Update-Datei enthält unter anderem ein Image mit Firmware für den Mikrocontroller. Dieses kann über das Bootloader-Protokoll übertragen werden. Um bei der Entwicklung Zeit zu sparen, wird der bereits vorinstallierte (und getestete!) Bootloader des Mikrocontroller Herstellers verwendet. Um diesen zu starten, gibt es zwei Möglichkeiten:
- Der Host-Controller setzt einen, dem Bootloader zugeordneten, Pin auf einen bestimmten Pegel, und führt anschließend einen Reset aus, indem er die Reset Leitung des Mikrocontrollers toggelt.
- Der Mikrocontroller springt eigenständig an die Adresse, auf der der Bootloader gespeichert ist.
Möglichkeit 1 hat einen ganz entscheidenden Nachteil: Es wird eine Resetleitung zwischen Host und Mikrocontroller benötigt. In unserem Fall würde das bedeuten, das ein Fehler in der Software des GUI-Controllers, jederzeit (auch während der Behandlung) zu einem Reset des Mikrocontrollers führen könnte. In der Medizintechnik dürfte dieses Problem es deutlich erschweren, eine Argumentation zu finden, warum der GUI-Controller in einer niedrigeren Risikoklasse eingestuft werden kann als der Mikrocontroller.
Möglichkeit 2 hat allerdings ebenfalls einen gravierenden Nachteil: Der Mikrocontroller muss über den Host einen Befehl bekommen, welcher den Sprung in den Bootloader startet. Das klingt zunächst trivial, man sollte sich aber im Klaren sein, das nach einem fehlgeschlagenen Update, in der Regel keine Firmware mehr vorhanden ist, die diesen Befehl versteht. Kappt der Nutzer also während dem Update die Stromversorgung, ist das Gerät hinterher unbrauchbar. Mit der BackUp-FW versuchen wir genau dieses Problem zu adressieren.
Lösung
Ziel ist es eine „abgespeckte“ Firmware auf dem Mikrocontroller unterzubringen, welche selbst nach einem fehlgeschlagenen Update immer noch in der Lage ist, ein weiteres Update durchzuführen. Sinnvollerweise, sollte sich diese an der Einsprungadresse befinden, von welcher die CPU nach einem Reset die erste Anweisung lädt (virtuelle Adresse 0x00).
Die BackUp-FW wird also nach einem Reset immer durchlaufen. Die folgende Abbildung zeigt den exemplarischen Ablauf einer BackUp-FW. Zu beachten ist das die BackUp-FW in ihren Funktionen möglichst eingeschränkt sein sollte, da diese bei einem Update nicht überschrieben wird. Im unteren Beispiel führt die BackUp-FW nur eine von zwei Aktionen durch:
- Ist eine Hauptapplikation mit gültiger Checksumme vorhanden, wird diese angesprungen.
- Ist keine gültige Checksumme vorhanden, wartet die BackUp-FW auf einen Befehl des Hosts und springt anschließend in den Bootloader.
Was es zu beachten gibt
Wann brauche ich eine BackUp-FW
der Einsatz der BackUp-FW ergibt nur dann Sinn, wenn auch tatsächlich auf einen vorinstallierten Bootloader zurückgegriffen werden kann, welcher beim Start nicht durchlaufen wird. Als Beispiel sind die STM32 Mikrocontroller zu nennen (Achtung, bei solchen mit zwei Flash-Panels gibt es eigene Regeln beim Umgang mit dem Bootloader!). Bei dieser Mikrocontroller Familie kann der Bootloader jederzeit aus der Hauptapplikation angesprungen werden. Andererseits stellt z.B. bei EFM32 und PIC32 Mikrocontrollern der Hersteller den Bootloader als SW-Projekt zur Verfügung, welcher in den meisten Fällen eh durch die Entwickler angepasst werden muss. Hier ist es daher empfehlenswert die Funktionen der BackUp-FW direkt im Bootloader unterzubringen.
Es kann außerdem sinnvoll sein, dass das Bootloader Protokoll dem Protokoll zwischen Host- und Peripheriecontroller angeglichen wird. Auch in diesem Fall empfiehlt es sich direkt einen eigenen Bootloader zu schreiben.
|
|
| M.Sc. Björn Schmitz, Software Entwickler E-Mail: schmitz@medtech-ingenieur.de Tel.: +49 9131 691 240 |
|
|
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf. |
|
Speicherbereiche schützen
Es kann sinnvoll sein den Speicherbereich, auf dem die BackUp-FW untergebracht ist, vor Schreibzugriffen zu schützen. So wird verhindert, dass der Host die Speicheraufteilung des Peripheriecontrollers kennen muss. Viele Mikrocontroller bieten die Möglichkeit den Speicher Page- oder Sektorweise zu schützen, um ein überschreiben beim Update-Vorgang zu verhindern.
BackUp-FW nicht überladen
Zwar liegt es nahe der BackUp-FW noch weitere Funktionen zuzuweisen, dies würde aber die Gefahr von Fehlern und damit der Notwendigkeit eines Updates deutlich erhöhen. Würde man die BackUp-FW überspielen und würde dieser Vorgang vor seinem Ende abgebrochen, verbliebe keine Firmware mehr, welche einen weiteren Sprung in den Bootloader ermöglicht. Ein Update der BackUp-FW sollte also nach Möglichkeit vermieden werden.
Ausblick
Im dritten und letzten Teil möchte ich über die Entwicklung eines Live Update Bootloaders schreiben. Bei diesem handelt es sich im Grunde genommen um keinen klassischen Bootloader, sondern eher um eine Erweiterung der Hauptapplikation um Funktionen die sonst dem Bootloader zugeordnet sind. So können Update im Hintergrund durchgeführt werden, ohne dass die Hauptapplikation ihre Arbeit einstellen muss.