In-line versus offline
Bei Energetika-VDS erfolgt das Firmware-Flashen auf unserer Linie über dedizierte Programmiervorrichtungen. Verlangt der Prüfplan des Kunden einen Funktionstest, wandert die Einheit mit bereits geladener Firmware in ein Partner-Testhaus weiter. AOI läuft in-house auf jeder Leiterplatte; FCT wird sourced.
Manche Hersteller integrieren das Flashen in dieselbe Vorrichtung wie den Funktionstest, sodass die Leiterplatte einmal eingelegt wird und zunächst die Programmierung, dann der Test läuft. Das funktioniert, wenn beide Schritte im selben Gebäude liegen. In unserem Aufbau sind Flashen und FCT räumlich getrennt: Wir flashen in-line, und das Partner-Testhaus fährt die Funktionssequenz gegen die soeben programmierte Firmware.
Für Produkte ohne Funktionstest im Scope wird die geflashte Leiterplatte nach AOI ohne zusätzliches Test-Tor versendet.
Programmierschnittstellen
Die Schnittstelle zum Chip variiert je nach Chip-Familie:
- SWD: ARM Cortex-M, geringe Pinzahl, schnell
- JTAG: ältere ARM, FPGA, auch Debug für viele Chips
- UART: Bootloader-basierte Programmierung, langsamer, aber keine zusätzlichen Pins erforderlich
- USB-DFU: USB-fähige Chips, Leiterplatte agiert während der Programmierung als USB-Device
- I2C, SPI: weniger üblich, für einige EEPROMs und Secure Elements
Die meisten Produktionsflashes nutzen SWD für ARM-Cortex-M-Bauteile und JTAG für ältere oder pinreiche Bauteile.
Multi-Image-Programmierung
Ein vernetztes Gerät hat in der Regel mehr als ein Firmware-Image:
- Bootloader: klein, signiert, nach der Produktion unveränderlich
- Applikation: Haupt-Firmware, OTA-aktualisierbar
- Dateisystem: Konfiguration, Web-Assets, Zertifikatsspeicher
- Manufacturing-Partition: Kalibrierung pro Einheit, Identität, Werksdaten
Die produktionsseitige Programmierung schreibt jedes Image der Reihe nach in die richtige Partition, mit der richtigen Signatur, falls zutreffend.
Signierte Bootloader-Ketten
Ein signierter Bootloader prüft die Signatur der Applikation, bevor er sie startet. Der Bootloader selbst wird durch den Secure-Boot-Mechanismus des Chips signiert (in eFuse gespeicherter Hash, ROM-basierte Verifikation).
Ergebnis: Ein Angreifer kann die Applikation nicht durch beliebigen Code ersetzen, da der Bootloader sich weigert, ihn zu starten. Ein Angreifer kann den Bootloader nicht ersetzen, da der Chip sich weigert, einen unsignierten Bootloader zu starten.
Produktionsseitig bedeutet das:
- Bootloader-Signierschlüssel generiert und im HSM gespeichert
- Applikations-Signierschlüssel generiert und im HSM gespeichert
- Produktionslinie greift über API auf die Signierung zu, hält nie den privaten Schlüssel
- eFuse gebrannt, um die Bootloader-Signatur dauerhaft zu fixieren
Toleranz gegenüber Stromausfall
Programmiersequenzen müssen einen Stromausfall mitten im Flashen tolerieren. Übliches Muster: Bootloader zuerst an einer festen Adresse schreiben, Applikation in einen separaten Bereich schreiben, ein "valid"-Flag im NVS erst nach Verifikation setzen. Fällt der Strom mitten im Schreibvorgang aus, sieht der Bootloader das fehlende valid-Flag und fällt auf bekannte gute Firmware zurück (oder verweigert den Start, je nach Richtlinie).
Verifikation
Nach dem Schreiben das geflashte Image zurücklesen und dessen Hash berechnen. Mit dem erwarteten Hash vergleichen. Bei Abweichung die Einheit als Flashing-Fehler kennzeichnen und an die Nacharbeit routen.
Dies fängt den seltenen Fall ab, in dem der Schreibvorgang selbst erfolgreich war, der Chip aber Müll geschrieben hat.
Protokollierung pro Einheit
Nach erfolgreichem Flash protokollieren:
- Firmware-Version
- Firmware-Hash
- Signierschlüssel-Referenz
- Programmier-Zeitstempel
- Seriennummer pro Einheit
Diese Daten leben in der Rückverfolgbarkeitsdatenbank der Produktion. Der Käufer kann später abfragen: "Welche Firmware wurde auf Serie XXX ausgeliefert, mit welchem Schlüssel signiert".