In-line verzus offline
V Energetika-VDS prebieha flashovanie firmvéru na našej linke cez špecializované programovacie prípravky. Keď zákaznícky plán testov vyžaduje funkčný test, kus s už nahraným firmvérom putuje k partnerskej testovacej dielni. AOI bežíme interne na každej doske; FCT je sourcovaný.
Niektorí výrobcovia zlučujú flashovanie do toho istého prípravku ako funkčný test, takže doska sa umiestni raz, najprv beží programovanie a potom test. Funguje to, keď obe operácie sídlia v tej istej budove. V našom nastavení sú flashovanie a FCT fyzicky oddelené: my flashujeme in-line a partnerská testovacia dielňa beží funkčnú sekvenciu voči práve naprogramovanému firmvéru.
Pri produktoch, ktoré nemajú v rozsahu funkčný test, flashovaná doska po AOI expeduje bez ďalšej testovacej brány.
Programovacie rozhrania
Rozhranie k čipu sa líši podľa rodiny čipu:
- SWD: ARM Cortex-M, nízky počet pinov, rýchle
- JTAG: starší ARM, FPGA, tiež debug pre mnoho čipov
- UART: programovanie cez bootloader, pomalšie, ale nevyžaduje extra piny
- USB-DFU: čipy podporujúce USB, doska sa počas programovania správa ako USB zariadenie
- I2C, SPI: menej časté, používané pre niektoré EEPROM a bezpečnostné prvky
Väčšina výrobných flashov používa SWD pre zariadenia ARM Cortex-M a JTAG pre staršie diely alebo diely s vyšším počtom pinov.
Programovanie viacerých obrazov
Pripojené zariadenie má zvyčajne viac ako jeden obraz firmvéru:
- Bootloader: malý, podpísaný, po výrobe nemenný
- Aplikácia: hlavný firmvér, aktualizovateľný cez OTA
- Súborový systém: konfigurácia, web assety, úložisko certifikátov
- Výrobný oddiel: kalibrácia po kuse, identita, výrobné dáta
Programovanie na výrobnej strane zapisuje každý obraz v poradí, do správneho oddielu, so správnym podpisom, ak je to relevantné.
Reťazce podpísaného bootloaderu
Podpísaný bootloader pred bootovaním kontroluje podpis aplikácie. Samotný bootloader je podpísaný mechanizmom secure boot čipu (hash uložený v eFuse, verifikácia v ROM).
Výsledok: útočník nemôže nahradiť aplikáciu ľubovoľným kódom, pretože bootloader ju odmietne nabootovať. Útočník nemôže nahradiť bootloader, pretože čip odmietne nabootovať nepodpísaný bootloader.
Na výrobnej strane to znamená:
- Podpisový kľúč bootloaderu vygenerovaný a uložený v HSM
- Podpisový kľúč aplikácie vygenerovaný a uložený v HSM
- Výrobná linka pristupuje k podpisovaniu cez API, súkromný kľúč nikdy nedrží
- eFuse vypálená, aby sa podpis bootloaderu uzamkol
Tolerancia výpadku napájania
Programovacie sekvencie musia tolerovať výpadok napájania uprostred flashovania. Bežný vzor: bootloader sa zapíše ako prvý na pevné miesto, aplikácia do samostatnej oblasti, „valid“ príznak v NVS sa nastaví až po verifikácii. Ak napájanie odpadne počas zápisu, bootloader uvidí chýbajúci „valid“ príznak a vráti sa na známy funkčný firmvér (alebo podľa politiky odmietne bootnúť).
Verifikácia
Po zápise prečítajte naflashovaný obraz späť a vypočítajte jeho hash. Porovnajte ho s očakávaným hashom. Ak sa líši, označte kus ako zlyhanie flashovania a presmerujte na rework.
Tým sa zachytí zriedkavý prípad, keď samotný zápis prešiel, ale čip zapísal nezmysly.
Logovanie po kuse
Po úspešnom flashe logujte:
- Verziu firmvéru
- Hash firmvéru
- Referenciu podpisového kľúča
- Časovú pečiatku programovania
- Sériové číslo kusa
Tieto dáta žijú vo výrobnej databáze traceability. Odberateľ môže neskôr dotazovať: „aký firmvér išiel na sériové číslo XXX, podpísaný ktorým kľúčom“.