Inline versus offline
V Energetika-VDS probíhá flashování firmwaru na naší lince prostřednictvím dedikovaných programovacích přípravků. Pokud testovací plán zákazníka vyžaduje funkční test, jednotka přechází k partnerské testovací firmě s firmwarem již nahraným. AOI probíhá v závodě u každé desky; FCT je zajišťováno externě.
Někteří výrobci integrují flashování do stejného přípravku jako funkční test, takže deska je umístěna jednou, programování proběhne jako první a poté test. To funguje, když oba kroky jsou v jedné budově. V naší konfiguraci jsou flashování a FCT fyzicky odděleny: flashování provádíme inline a partnerská testovací firma provádí funkční sekvenci oproti právě naprogramovanému firmwaru.
Pro výrobky bez funkčního testu v rozsahu se flashovaná deska dodává po AOI bez dalšího testovacího bodu.
Programovací rozhraní
Rozhraní k čipu se liší podle rodiny čipů:
- SWD: ARM Cortex-M, nízký počet pinů, rychlý
- JTAG: starší ARM, FPGA, také ladění pro mnohé čipy
- UART: programování přes bootloader, pomalejší, ale bez dalších pinů
- USB-DFU: čipy s USB, deska funguje jako USB zařízení během programování
- I2C, SPI: méně časté, používané pro některé EEPROM a bezpečnostní prvky
Většina výrobních flashování používá SWD pro zařízení ARM Cortex-M a JTAG pro starší nebo součásti s vyšším počtem pinů.
Programování více obrazů
Připojené zařízení má obvykle více než jeden obraz firmwaru:
- Bootloader: malý, podepsaný, neměnný po výrobě
- Aplikace: hlavní firmware, aktualizovatelný OTA
- Souborový systém: konfigurace, webové podklady, úložiště certifikátů
- Výrobní oblast: individuální kalibrace, identita, tovární data
Výrobní programování zapisuje každý obraz v posloupnosti, do správné oblasti, s příslušným podpisem, je-li relevantní.
Podepsané bootloader řetězce
Podepsaný bootloader ověřuje podpis aplikace před jejím spuštěním. Samotný bootloader je podepsán bezpečnostním mechanismem čipu (hash uložený v eFuse, ověření z ROM).
Výsledek: útočník nemůže nahradit aplikaci libovolným kódem, protože bootloader odmítne spustit nepodepsanou aplikaci. Útočník nemůže nahradit bootloader, protože čip odmítne spustit nepodepsaný bootloader.
Na výrobní straně to znamená:
- Podpisový klíč bootloaderu vygenerován a uložen v HSM
- Podpisový klíč aplikace vygenerován a uložen v HSM
- Výrobní linka přistupuje k podepisování přes API, nikdy nedrží soukromý klíč
- eFuse vypálen pro uzamčení podpisu bootloaderu
Tolerance výpadku napájení
Programovací sekvence musí tolerovat výpadek napájení uprostřed flashování. Obvyklý vzor: nejprve zapsat bootloader na pevné místo, zapsat aplikaci do samostatné oblasti, nastavit příznak „platný" v NVS pouze po ověření. Pokud napájení vypadne uprostřed zápisu, bootloader vidí chybějící platný příznak a vrátí se ke known-good firmwaru (nebo odmítne spustit, podle politiky).
Ověření
Po zápisu načtěte zpět flashovaný obraz a vypočítejte jeho hash. Porovnejte s očekávaným hashem. Pokud se liší, označte jednotku jako selhání flashování a přesměrujte k přepracování.
To zachytí vzácný případ, kdy samotný zápis byl úspěšný, ale čip zapsal nesmysl.
Protokolování pro každou jednotku
Po úspěšném flashování zaprotokolujte:
- Verzi firmwaru
- Hash firmwaru
- Odkaz na podpisový klíč
- Časové razítko programování
- Sériové číslo jednotky
Tato data jsou uložena v databázi výrobní dohledatelnosti. Kupující může později dotazovat: „jaký firmware byl dodán na sériovém čísle XXX, podepsán jakým klíčem".