In-line versus offline
Bij Energetika-VDS gebeurt firmware-flashing op onze lijn via dedicated programmeerfixtures. Wanneer het testplan van de klant functionele test vereist, gaat de unit door naar een partner-testhuis met de firmware al geladen. AOI draait in-house op elke board; FCT wordt extern afgenomen.
Sommige fabrikanten combineren flashing in dezelfde fixture als de functionele test, zodat de board een keer wordt geplaatst en eerst geprogrammeerd, dan getest wordt. Dat werkt als beide stappen in hetzelfde gebouw plaatsvinden. In onze opstelling zijn flashing en FCT fysiek gescheiden: wij draaien flashing in-line, en het partner-testhuis voert de functionele sequentie uit tegen de zojuist geprogrammeerde firmware.
Voor producten zonder functionele test in scope wordt de geflashte board na AOI verzonden zonder extra testgate.
Programmeerinterfaces
De interface naar de chip verschilt per chipfamilie:
- SWD: ARM Cortex-M, lage pintelling, snel
- JTAG: legacy ARM, FPGA, ook debug voor veel chips
- UART: programmering via bootloader, trager maar zonder extra pinnen
- USB-DFU: USB-capable chips, de board fungeert tijdens programmering als USB-apparaat
- I2C, SPI: minder gangbaar, gebruikt voor sommige EEPROM's en secure elements
De meeste productieflashes gebruiken SWD voor ARM Cortex-M-apparaten en JTAG voor oudere of hogere pin-count-onderdelen.
Programmeren van meerdere images
Een connected device heeft meestal meer dan een firmware-image:
- Bootloader: klein, gesigneerd, onveranderlijk na productie
- Applicatie: hoofdfirmware, OTA-update-baar
- Filesystem: configuratie, web-assets, certificate store
- Manufacturing-partitie: kalibratie per unit, identiteit, fabrieksdata
Productiezijdig programmeren schrijft elk image op volgorde, in de juiste partitie, met de juiste signing indien van toepassing.
Gesigneerde bootloader-ketens
Een gesigneerde bootloader controleert de handtekening van de applicatie voor het opstarten. De bootloader zelf wordt gesigneerd door het secure boot-mechanisme van de chip (eFuse-opgeslagen hash, ROM-gebaseerde verificatie).
Resultaat: een aanvaller kan de applicatie niet vervangen door willekeurige code, omdat de bootloader weigert te starten. Een aanvaller kan de bootloader niet vervangen, omdat de chip weigert een ongesigneerde bootloader te starten.
Productiezijdig betekent dit:
- Bootloader-signingsleutel gegenereerd en bewaard in HSM
- Applicatie-signingsleutel gegenereerd en bewaard in HSM
- Productielijn benadert signing via API en houdt nooit de privesleutel
- eFuse gebrand om de bootloader-handtekening vast te zetten
Bestand tegen stroomverlies
Programmeersequenties moeten stroomverlies tijdens flash kunnen verdragen. Veelgebruikt patroon: bootloader eerst naar een vaste locatie schrijven, applicatie naar een aparte regio schrijven, een "valid"-vlag in NVS pas zetten na verificatie. Valt de stroom uit tijdens het schrijven, dan ziet de bootloader de ontbrekende valid-vlag en valt terug op een bekende werkende firmware (of weigert te starten, afhankelijk van het beleid).
Verificatie
Na schrijven het geflashte image teruglezen en de hash berekenen. Vergelijken met de verwachte hash. Bij verschil de unit markeren als flash-fout en routen naar rework.
Dit vangt het zeldzame geval op waarin de write zelf slaagde maar de chip onzin heeft geschreven.
Logging per unit
Na een geslaagde flash loggen:
- Firmwareversie
- Firmware-hash
- Verwijzing naar signingsleutel
- Timestamp van de programmering
- Serienummer per unit
Deze data leeft in de productie-traceability-database. De koper kan later opvragen: "welke firmware is op serienummer XXX uitgeleverd, gesigneerd met welke sleutel".