Bootloader und Firmware-Wiederherstellung für Lesestifte – Leitfaden für B2B-Einkäufer

Zielgruppe: Dieser Leitfaden richtet sich an Hardware-Engineering-Leads, OEM-Firmware-Architekten und Field-Service-Manager, die die Bootloader-Architektur, das Dual-Bank-Flash, die OTA-Wiederherstellung und das DFU-Modus-Verhalten eines Reading-Pen-SKU validieren müssen, bevor sie die Massenproduktion freigeben. Sekundäre Leser sind QA-Manager, die Brick-Recovery-Testpläne erstellen, sowie OTA-Update-Operatoren, die groß angelegte Flotten-Updates verwalten.

Ein mexikanischer Distributor rief uns Mitte 2025 an, weil ein Firmware-OTA-Update 312 seiner 1.800 K7-Pens im Feld gebrickt hatte. Die Pens hatten das OTA-Payload über BLE empfangen, begannen mit dem Schreiben in den Flash und verloren dann mitten im Schreibvorgang die Stromversorgung, da die Pens auf Schulwagen mit unzuverlässigem USB-C-Kontakt lagen. Der Pen schaltete sich ein, die grüne LED blinkte 200 ms lang und wurde dann dunkel. Der Brick wurde durch eine fehlende Dual-Bank-Flash-Architektur verursacht: Der Pen hatte nur eine Flash-Bank, und das OTA-Update überschrieb die laufende Firmware. Als die Stromversorgung unterbrochen wurde, war die neue Firmware unvollständig und der Pen konnte nicht booten. Die Lösung bestand darin, eine zweite Flash-Bank sowie einen Bootloader hinzuzufügen, der immer von der gültigen Bank bootet. Jeder Reading Pen in unserem Katalog (B1, B2, F8, K7, KF1, L5, P2, Q6, Q8, T2, Y6) verwendet eine Dual-Bank-Bootloader-Architektur, und dieser Leitfaden erläutert, wie sich diese Architektur auf die OTA-Zuverlässigkeit und die Brick-Wiederherstellung abbildet.

1. Die Dual-Bank-Flash-Architektur

Wir verwenden im gesamten Katalog eine Dual-Bank-Flash-Architektur. Der MCU verfügt über 8 MB oder 16 MB internen Flash, der in zwei gleich große Banks aufgeteilt ist. Bank A enthält die aktuell laufende Firmware; Bank B enthält die vorherige Firmware oder das eingehende OTA-Payload. Der Bootloader liest beim Booten die Firmware-Version aus jeder Bank und wählt die gültige Bank aus.

Die Bank-Auswahllogik ist:

1. Wenn Bank A gültig ist und Bank A Version > Bank B Version, von Bank A booten.
2. Wenn Bank A gültig und Bank B ungültig ist, von Bank A booten.
3. Wenn Bank A ungültig und Bank B gültig ist, von Bank B booten und Bank A als zu re-schreibend markieren.
4. Wenn beide Banks ungültig sind, in den DFU-Modus (Device Firmware Upgrade) wechseln und auf einen USB-C-Firmware-Upload warten.

Die Gültigkeitsprüfung ist eine CRC32 über das Firmware-Image, die vom Bootloader beim Booten berechnet wird. Die CRC32 wird im Firmware-Header gespeichert, und der Bootloader liest den Header, berechnet die CRC32 über das Image und vergleicht. Stimmt die CRC32 überein, ist die Bank gültig. Stimmt sie nicht überein, ist die Bank ungültig.

Der Bootzeit-Overhead der Dual-Bank-Prüfung beträgt 240 ms und ist gegenüber dem Kaltstart von 1,8 Sekunden vernachlässigbar.

2. Der OTA-Update-Ablauf

Der OTA-Update-Ablauf folgt bei jeder SKU einer strikten Reihenfolge, um Brick-Vorfälle zu verhindern:

1. Der Host (Mobile App oder PC-Tool) lädt das neue Firmware-Image vom Cloud-Server herunter.
2. Der Host berechnet die CRC32 über das neue Firmware-Image und verifiziert sie anhand der Cloud-Signatur.
3. Der Host öffnet eine BLE-Verbindung zum Stift und authentifiziert sich mit einer 6-stelligen PIN.
4. Der Host überträgt das Firmware-Image in 4-KB-Chunks über BLE an den Stift.
5. Der Stift schreibt jeden Chunk in Bank B (die inaktive Bank) und verifiziert die CRC32 jedes Chunks.
6. Nachdem alle Chunks übertragen wurden, verifiziert der Stift die vollständige CRC32 von Bank B.
7. Der Stift setzt ein Flag „Pending Update“ im always-on RTC-Bereich.
8. Der Stift startet neu. Der Bootloader prüft das Flag, tauscht den aktiven Bank-Zeiger und bootet vom neuen Image.

Der kritische Schritt ist Schritt 5: das Schreiben in die inaktive Bank. Bank A wird bis Schritt 8 nicht angefasst, nachdem das neue Image vollständig geschrieben und verifiziert wurde. Verliert der Stift in den Schritten 4–7 die Stromversorgung, erkennt der Bootloader eine unvollständige Bank B und eine gültige Bank A und bootet von Bank A. Der Stift ist nicht gebrickt.

Das Problem mit dem mexikanischen K7 betraf eine andere SKU (ein älteres Design) ohne Dual-Bank-Architektur. Der aktuelle K7 mit Firmware 1.9.5 verfügt über die Dual-Bank-Architektur und den oben beschriebenen OTA-Ablauf. Wir hatten in den 24 Monaten seit Einführung der Architektur im gesamten Katalog keinen Brick-Vorfall bei einer Dual-Bank-SKU.

3. Der DFU-Modus und die Brick-Wiederherstellung

Sind sowohl Bank A als auch Bank B ungültig (was im Normalbetrieb nie vorkommen sollte), wechselt der Stift in den DFU-Modus. Im DFU-Modus stellt der Bootloader eine USB-C-Schnittstelle bereit, die einen Raw-Firmware-Upload akzeptiert. Der DFU-Modus wird durch eine schnell blinkende rote LED signalisiert (3 Hz, 50 % Tastverhältnis).

Das DFU-Upload-Tool ist ein herstellerspezifisches Kommandozeilenwerkzeug für Windows, macOS oder Linux. Das Tool lädt das Firmware-Image in 64-KB-Chunks auf den Stift, und der Bootloader schreibt jeden Chunk in Bank A. Nach dem vollständigen Upload verifiziert der Bootloader die CRC32 und bootet von Bank A. Der DFU-Upload dauert über USB 2.0 High Speed 18 Sekunden für ein 8-MB-Image und 36 Sekunden für ein 16-MB-Image.

Der DFU-Modus ist auch im Normalbetrieb zugänglich, indem die Power-Taste 12 Sekunden lang gedrückt wird. Das 12-Sekunden-Halten ist eine bewusste Entscheidung, um ein versehentliches Aufrufen des DFU-Modus zu verhindern. Die schnell blinkende rote LED signalisiert dem Benutzer klar, dass sich der Stift im DFU-Modus befindet.

4. Die Bootloader-Version und der Update-Mechanismus

Der Bootloader selbst ist in einem separaten Read-Only-Flash-Bereich gespeichert, der nicht durch das OTA-Update überschrieben werden kann. Die Bootloader-Version ist unabhängig von der Firmware-Version. Seit 2023 haben wir drei Bootloader-Versionen ausgeliefert:

• Bootloader v1.0 (2023): Basis-Dual-Bank, CRC32-Prüfung, DFU-Modus.
• Bootloader v1.2 (2024): Firmware-Signaturverifizierung mittels ECDSA-P256 hinzugefügt.
• Bootloader v2.0 (2025): Rollback-Schutz hinzugefügt (kann keine ältere Firmware-Version booten als die aktuell in Bank A, außer explizit aktiviert).

Der Bootloader kann aktualisiert werden, jedoch nur über einen USB-C-Firmware-Upload, der direkt auf den Bootloader-Bereich abzielt. Das Bootloader-Update erfordert ein 12-sekündiges Halten der Power-Taste, und die LED leuchtet während des Updates blau. Wir haben in der Geschichte der Produktlinie zweimal Bootloader-Updates herausgegeben: v1.0 auf v1.2 Mitte 2024 und v1.2 auf v2.0 Anfang 2025. Die Updates wurden auf über 12.000 im Feld eingesetzten Stiften mit einer Erfolgsquote von 100 % angewendet.

5. Firmware-Signaturverifizierung

Seit Bootloader v1.2 ist jedes Firmware-Image mit einer ECDSA-P256-Signatur signiert. Die Signatur ist im Firmware-Header neben der CRC32 gespeichert. Der Bootloader hält den öffentlichen Schlüssel in einem One-Time-Programmable-Bereich (OTP) der MCU, und der öffentliche Schlüssel wird während der Werksprovisionierung gesetzt. Der Bootloader verifiziert die Signatur beim Booten, bevor er auf das neue Image wechselt.

Die Signaturverifizierung schützt gegen ein bösartiges OTA-Payload. Ohne die Signatur könnte ein Angreifer ein Firmware-Image mit gültiger CRC32, aber bösartigem Code erstellen. Die ECDSA-P256-Signatur erfordert einen 32-Byte-Privatschlüssel, der nur im Werk vorliegt. Wir hatten in den 24 Monaten seit Aktivierung der Signaturverifizierung keinen einzigen bösartigen OTA-Vorfall.

Ein wichtiger Punkt: Der Signaturschlüssel ist pro Werk, nicht pro Kunde. Möchte ein OEM-Käufer einen kundenspezifischen Signaturschlüssel (sodass das Werk keine Firmware auf die Stifte des OEMs pushen kann), können wir im OTP-Bereich einen kundenspezifischen Schlüssel mit einer BOM-Erhöhung von 0,04 USD pro Einheit und einer 4-wöchigen Provisionierungseinrichtung bereitstellen.

6. Rollback-Schutz

Bootloader v2.0 hat den Rollback-Schutz hinzugefügt. Der Bootloader speichert die Versionsnummer der zuletzt gebooteten Firmware im always-on RTC-Bereich und verweigert das Booten einer älteren Firmware-Version. Der Schutz verhindert, dass ein Angreifer die Firmware auf eine verwundbare Version downgradet. Der Schutz kann durch einen OEM-spezifischen Schlüssel im Firmware-Header deaktiviert werden.

Für OEM-Käufer, die Downgrade-Fähigkeit benötigen (z. B. für Rollback im Flottenmanagement während eines gestaffelten Rollouts), können wir den Rollback-Schutz kundenbezogen deaktivieren. Das Disable-Bit wird bei der Werksprovisionierung im Firmware-Header gesetzt und kann nicht durch das OTA-Payload geändert werden.

7. Stromausfallverhalten während OTA

Der OTA-Schreibvorgang auf Bank B ist so konzipiert, dass er einen Stromausfall an jedem Punkt übersteht. Das Schreiben verwendet ein Journaling-Schema: Jeder 4-KB-Chunk wird mit einem 16-Byte-Header geschrieben, der eine Sequenznummer, eine CRC32 und ein „Complete“-Flag enthält. Der Bootloader kann einen unvollständigen Schreibvorgang durch Prüfung des „Complete“-Flags und der Sequenznummer erkennen.

Erkennt der Bootloader einen unvollständigen Schreibvorgang, markiert er die Bank als ungültig und bootet von der gültigen Bank. Die ungültige Bank wird für das nächste OTA zum Überschreiben freigegeben. Es gibt keinen „verlorenen“ Flash-Speicher, da der Journaling-Header Teil des 4-KB-Chunks ist und der Bootloader denselben Chunk beim nächsten Schreiben wiederverwendet.

Das Journal-Write-Schema hat im Worst Case 4 KB inkonsistente Daten nach einem Stromausfall, aber die CRC32-Prüfung erkennt dies und die Bank wird als ungültig markiert. Der Stift wird nie gebrickt.

8. Der Bootloader-OTA-Selbsttest

Jede Produktionscharge von L5, Q6, Q8, T2 und Y6 durchläuft vor dem Versand einen 12-Einheiten-Bootloader-Selbsttest. Der Selbsttest führt Folgendes durch:

1. Ein gültiges Firmware-Image auf Bank B schreiben und verifizieren, dass der Bootloader davon bootet.
2. Schreiben Sie ein beschädigtes Image (fehlerhafte CRC32) in Bank A und prüfen Sie, ob der Bootloader auf Bank B zurückfällt.
3. Schreiben Sie ein beschädigtes Image in beide Bänke und prüfen Sie, ob der Bootloader in den DFU-Modus wechselt.
4. Laden Sie ein Firmware-Image über den DFU-Modus hoch und prüfen Sie, ob der Bootloader davon startet.

Im Jahr 2025 haben wir von 168 Losen 3 aufgrund von Bootloader-Selbsttest-Fehlern zurückgehalten. Zwei wurden auf eine fehlerhafte Charge von Flash-Speicher-ICs eines Tier-2-Lieferanten zurückgeführt; das dritte war eine Bootloader-Revisionsabweichung, die durch die CRC32-Prüfung erkannt wurde.

9. Felddiagnose bei Boot-Problemen

Wenn ein Kunde einen Stift meldet, der nicht startet, bitten wir ihn, die 12-Sekunden-Powertaste-Halteroutine auszuführen, um in den DFU-Modus zu gelangen. Wenn der Stift in den DFU-Modus wechselt (schnell blinkende rote LED), liegt das Problem an einem beschädigten Firmware-Image in beiden Bänken, das per DFU-Upload wiederhergestellt werden kann. Wenn der Stift nicht in den DFU-Modus wechselt (keine LED-Reaktion), liegt ein Hardwarefehler vor, der im Feld nicht behebbar ist und eine Werksreparatur erfordert.

Das Verhältnis von DFU-wiederherstellbaren zu hardwarebedingten Boot-Fehlern in unseren Felddaten von 2025 beträgt 87:13. Die 87 % werden typischerweise durch ein OTA-Update verursacht, das durch einen Stromausfall oder eine BLE-Trennung während der Schreibphase unterbrochen wurde. Die 13 % werden typischerweise durch einen Ausfall des Flash-Speicher-ICs, einen Kurzschluss auf der Stromschiene oder einen Steckerschaden verursacht.

Wir stellen ein kundenorientiertes DFU-Tool bereit, das jeder OEM-Käufer mit eigenem Branding versehen und an seine Endnutzer verteilen kann. Das Tool läuft unter Windows, macOS, Linux und Android (über USB-C OTG) und enthält eine Schritt-für-Schritt-Anleitung für nicht-technische Anwender.

10. 12-Monats-Roadmap für die Bootloader-Technologie

Wir verfolgen drei Bootloader-Verbesserungen, die bis Q4 2026 in den Katalog aufgenommen werden. Erstens eine A/B/C-Dreibank-Architektur auf einer zukünftigen Premium-SKU, die es ermöglicht, zwei OTA-Payloads gleichzeitig zu speichern und so einen sofortigen Rollback auf eine als bekannt gut geltende Version ohne erneutes Herunterladen zu erlauben. Zweitens eine Option für verschlüsselte Firmware auf einer zukünftigen Premium-SKU, die AES-128 verwendet, um das Firmware-Image im Ruhezustand zu verschlüsseln und so vor Flash-Dump-Angriffen zu schützen. Drittens ein cloudkoordinierter OTA-Mechanismus, der die OTA-Schreibphase in ein bekanntermaßen sicheres Ladefenster legt (Stift auf Ladegerät, Akku > 50 %, Temperatur < 35 °C), um das Risiko eines durch Stromausfall verursachten Brick-Vorfalls zu minimieren.

Wir werden einen Folgebericht veröffentlichen, sobald die Dreibank-Architektur in Feldversuchen ausgeliefert wird. Bis dahin ist die Bootloader-Architektur in unserem Katalog ausgereift, gut validiert und gut unterstützt, und wir laden jeden OEM-Käufer mit individuellen Firmware-Update-Anforderungen ein, sich für eine Machbarkeitsprüfung an unser ODM-Lesestifte-Team zu wenden.

Weiterführende Inhalte

• Lesestift-Firmware-Architektur im Detail erklärt
• Lesestift-OTA-Firmware-Update-Mechanismus
• Lesestift-Watchdog-Timer und System-Reset
• Lesestift-RTC Echtzeituhr und Zeitmessung
• Lesestift-PMIC Power-Management-IC
• Lesestift-Energieverwaltung und Laufzeitoptimierung
• Lesestift-Fehlerbehebungs-Playbook
• Lesestift-Qualitätskontrolle und AQL-Standards