Firmware-Updates: CDC vs DFU – sicher & reproduzierbar

Firmware-Updates sind unvermeidbar. Wenn Ihr STM32-Gerät über USB angebunden ist und Sie eine Android-Begleit-App ausliefern, wählen Sie in der Praxis zwischen einem einfachen Applikations-Protokoll über USB-CDC oder dem integrierten USB-DFU-Modus. So entscheiden Sie – und liefern einen sicheren, wiederholbaren Update-Flow.

Begriffe: Was meinen wir mit CDC und DFU

• USB-CDC: Ihre Firmware stellt eine virtuelle COM-Schnittstelle bereit; die Android-App (USB-Host) sendet das Image über ein kleines, dokumentiertes Protokoll.

• USB-DFU: Das Gerät bootet in einen DFU-Bootloader und meldet sich als DFU-Interface an; der Host schreibt das Image über die DFU-State-Machine.

Wann CDC (Applikations-Updater) wählen

• In-App-UX: Ein Button, Fortschrittsbalken, Logs – ohne USB-Identitätswechsel.

• Parameter + Firmware in einer Sitzung aktualisieren.

• Volle Kontrolle über Verschlüsselung/Signatur und Versionierung.

• Sie sind bereit, ein kleines, gut dokumentiertes Protokoll zu pflegen.

Wann DFU (Bootloader-Updater) wählen

• Update ist vom laufenden App-Code isoliert (sicherer bei defekter App).

• Recovery möglich, auch wenn die Application-Section korrupt ist.

• Standard-USB-Klasse, minimales App-Protokoll.

• Sie akzeptieren kurzen Reboot und Neu-Enumeration als DFU.

Entscheidungsregel (praktisch)

• Brick-Resistenz & Recovery im Fokus → DFU.

• Nahtlose UX, eng mit App-Features/Telemetrie verzahnt → CDC (mit robustem Fail-Safe).

Empfohlener sicherer Update-Flow (für beide)

• Version & Integrität: SemVer, Image signieren/HMAC; vor dem Flashen verifizieren.

• Pre-Checks: Power OK, Temperatur im Bereich, freier Flash; Device-ID + aktuelle Version loggen.

• Transfer: Chunked (512–2048 B), ACK/NAK, CRC pro Chunk + finaler Digest.

• Commit: in inaktiven Slot schreiben, verifizieren, Boot-Flag setzen, Reboot; Bootloader prüft erneut.

• Rollback: Last-Known-Good behalten; fällt Health-Check nach Boot durch, automatisch zurückrollen.

• Telemetrie: Device-ID, alt/neu-Version, Transferzeit, Retries, CRC-Ergebnis, Commit-Status erfassen.

Design-Hinweise für CDC-Updater

• Protokoll: HEADER (Magic, Länge, Version) → CHUNKS (Seq, Len, CRC) → FOOTER (Digest/Signatur).

• Flow-Control: Bulk-Endpoints, getaktete Writes, Bestätigung pro Chunk.

• Security: Signatur prüfen vor Erase, sichere Schlüsselablage, Anti-Replay Nonce.

• Health-Check: Nach Reboot meldet Gerät boot_ok; fehlt das Signal, Recovery auslösen.

Design-Hinweise für DFU-Updater

• Bootloader: ST-DFU oder eigener DFU-Class-Loader mit Signaturprüfung.

• Partitionen: Slot A/B oder App + Backup; niemals das einzige gute Image überschreiben.

• UX: App sendet Jump-to-DFU, reconnect als DFU, streamt das Image.

• Recovery: Hardware-Gesten (BOOT0/Buttons), um DFU zu erzwingen, wenn die App tot ist.

Android-Seite (USB-Host) – Checkliste

• Permission via UsbManager anfordern; VID/PID persistieren.

• Bulk-Transfers mit sinnvollen Timeouts und Exponential Backoff.

• Datei streamen → Buffer (Image nicht komplett in RAM laden).

• Screen wach halten; „Nicht trennen“-Banner anzeigen.

• Audit-Logs schreiben (Device-ID, Versionen, Ergebnis).

Häufige Fallstricke

• In-Place-Update ohne Backup (kein Rollback).

• Kein End-to-End-Integritätscheck.

• „Success“ deklarieren ohne Post-Boot Health-Signal.

• Zu enge Timeouts, die langsame, aber gültige Transfers als Fehler markieren.

• Kein Replay-Schutz (altes, verwundbares Image erneut installierbar).

Minimale Abnahme-Checkliste vor dem Release

• Image-Signatur/Verifikation nachgewiesen (Bad-Signature-Test schlägt fehl).

• Power-Loss-Tests während Transfer/Commit erholen sich korrekt.

• Rollback verifiziert durch erzwungenen Health-Check-Fehler.

• Android-Log enthält Device-ID, alt/neu-Versionen, Result.

• User-Recovery auf DFU oder voriges Image ohne Spezialtools möglich.

Roadmap – wo passt das hinein?

CDC oder DFU anhand UX vs. Recovery wählen, Dual-Slot/Rollback implementieren, dann Signierung & Telemetrie ergänzen. Sobald zuverlässig, staged Rollouts fahren und Update-Qualität überwachen.

Verwandte Leistungen

• STM32 Motor-Control Consulting — Remote-Tests & Android-Integration

• STM32CubeIDE + RTOS mit ESP32