Kurz erklärt
Ein robustes Firmware-Update braucht einen definierten Weg zurück zu einem startfähigen Gerät. Bevor die Übertragung implementiert wird, sollten Sie festlegen, was bei Stromausfall während Löschen, Schreiben, Prüfen und Aktivieren des neuen Images geschieht.
System-Bootloader und Produkt-Update unterscheiden
Der im STM32 vorhandene System-Bootloader und ein eigener Produkt-Bootloader erfüllen nicht automatisch dieselben Aufgaben. Unterstützte Schnittstellen und Aktivierungsbedingungen sind bauteilabhängig; ST beschreibt sie in AN2606. Prüfen Sie die genaue Bestellnummer statt nur die STM32-Familie. STMicroelectronics — AN2606
Ein Werkstattzugang über einen Programmieradapter kann für die Entwicklung ausreichen, aber für ein eingebautes Gerät ungeeignet sein. Beschreiben Sie, wer ein fehlerhaftes Gerät erreichen kann und welche Verbindung dann noch verfügbar ist. Daraus ergibt sich die erforderliche Wiederherstellungsstrategie.
Speicherbedarf vor der Architekturentscheidung berechnen
Erfassen Sie Bootloader, Anwendung, Konfigurationsdaten und benötigten Arbeitsbereich. Reservieren Sie Platz für die erwartete Weiterentwicklung der Anwendung. Ob zwei Images intern Platz finden oder externer Speicher erforderlich ist, muss für das gewählte Bauteil berechnet werden.
MCUboot beschreibt unter anderem Test-Updates mit anschließender Bestätigung und Rückkehr zum vorherigen Image. Dieses Prinzip ist eine mögliche Architektur, aber keine automatisch vorhandene Eigenschaft jedes STM32-Projekts. Prüfen Sie die gewählte Implementierung und deren Speicheranforderungen. MCUboot — Bootloader design
Ein neues Image erst nach Prüfung aktivieren
Definieren Sie getrennte Zustände für empfangen, geprüft, zum Test gestartet und bestätigt. Ein Download-Ende sollte nicht allein als Freigabe gelten. Zur Prüfung gehören die Zuordnung zum Gerätetyp, zulässige Größe und Version sowie die Integrität des Images.
Eine Prüfsumme erkennt bestimmte Übertragungsfehler, weist aber keine vertrauenswürdige Herkunft nach. Wenn die Bedrohungsanalyse dies erfordert, planen Sie eine kryptografische Signaturprüfung mit geschütztem Vertrauensanker ein. Schlüsselverwaltung und Freigabeverfahren gehören dann zum Produktprozess.
Fehlerfälle gezielt reproduzieren
Unterbrechen Sie die Versorgung an verschiedenen Stellen des Update-Ablaufs und protokollieren Sie den Folgezustand. Testen Sie außerdem ein unvollständiges Image, eine falsche Hardwarekennung und eine Anwendung, die startet, aber ihren Gesundheitstest nicht besteht.
Ein sinnvolles Abnahmekriterium lautet beispielsweise: Nach jedem definierten Abbruchfall startet die vorherige freigegebene Anwendung oder das dokumentierte Wiederherstellungsverfahren. Ob ein automatischer Neustart im jeweiligen Gerät zulässig ist, muss anhand seiner Funktion entschieden werden.
Für das Update-Konzept festhalten
- Exakte MCU- und Hardwareversion sowie verfügbaren Speicher dokumentieren.
- Erreichbaren Wiederherstellungsweg festlegen.
- Image-Zustände und Freigabebedingungen beschreiben.
- Konfigurationsdaten und deren Versionswechsel berücksichtigen.
- Stromausfalltests mit Firmwarekennung und Ergebnis archivieren.
Häufige Fragen
Sind zwei Flash-Bänke allein ausreichend?
Nein. Zusätzlich werden ein passender Update-Ablauf, konsistente Zustandsdaten und eine geprüfte Startentscheidung benötigt. Die konkreten Flash-Eigenschaften sind geräteabhängig.
Muss jedes Gerät ein OTA-Update erhalten?
Nein. Eine lokale Wartungsschnittstelle kann passend sein. Entscheidend sind Zugänglichkeit, Ausfallkosten, Wartungsablauf und die Anforderungen an die Herkunft der Firmware.
Technische Quellen
Passende Entwicklungsleistung