In-line versus offline
Hos Energetika-VDS skjer fastvareflashing på linjen vår gjennom dedikerte programmeringsfiksturer. Når kundens testplan krever funksjonell test, går enheten videre til en partner-testlab med fastvaren allerede lastet. AOI kjøres internt på hvert kort; FCT er sourcet.
Noen produsenter slår sammen flashing i samme fikstur som funksjonell test, slik at kortet plasseres én gang og programmering kjøres først, så test. Det fungerer når begge stegene bor i samme bygning. I vårt oppsett er flashing og FCT fysisk adskilt: vi kjører flashing in-line, og partner-testlaben kjører den funksjonelle sekvensen mot den nettopp programmerte fastvaren.
For produkter uten funksjonell test i scope, sendes det flashede kortet etter AOI uten ekstra testport.
Programmeringsgrensesnitt
Grensesnittet mot brikken varierer etter brikkefamilie:
- SWD: ARM Cortex-M, lav pinantall, raskt
- JTAG: legacy ARM, FPGA, også debug for mange brikker
- UART: bootloader-basert programmering, tregere, men ingen ekstra pinner trengs
- USB-DFU: USB-kompatible brikker, kortet opptrer som USB-enhet under programmering
- I2C, SPI: mindre vanlig, brukes for noen EEPROM-er og secure elements
De fleste produksjonsflashinger bruker SWD for ARM Cortex-M-enheter og JTAG for eldre eller deler med høyere pinantall.
Programmering med flere bilder
En tilkoblet enhet har vanligvis mer enn ett fastvarebilde:
- Bootloader: liten, signert, uforanderlig etter produksjon
- Applikasjon: hovedfastvare, OTA-oppdaterbar
- Filsystem: konfigurasjon, web-ressurser, sertifikatlager
- Manufacturing partition: per-enhet-kalibrering, identitet, fabrikkdata
Programmering på produksjonssiden skriver hvert bilde i sekvens, i riktig partisjon, med riktig signering der det er aktuelt.
Signerte bootloader-kjeder
En signert bootloader sjekker signaturen til applikasjonen før den booter den. Bootloaderen selv er signert av brikkens secure boot-mekanisme (eFuse-lagret hash, ROM-basert verifisering).
Resultat: en angriper kan ikke erstatte applikasjonen med vilkårlig kode, fordi bootloaderen vil nekte å boote den. En angriper kan ikke erstatte bootloaderen, fordi brikken vil nekte å boote en usignert bootloader.
På produksjonssiden betyr dette:
- Bootloader-signeringsnøkkel generert og lagret i HSM
- Applikasjons-signeringsnøkkel generert og lagret i HSM
- Produksjonslinjen får tilgang til signering via API, holder aldri privatnøkkelen
- eFuse brent for å låse bootloader-signaturen på plass
Toleranse for strømtap
Programmeringssekvenser må tolerere strømtap midt i flashing. Vanlig mønster: skriv bootloader først til en fast plass, skriv applikasjon til et separat område, sett et "valid"-flagg i NVS først etter verifisering. Hvis strømmen ryker midt i skrivingen, ser bootloaderen det manglende valid-flagget og faller tilbake til kjent-god fastvare (eller nekter å boote, avhengig av policy).
Verifisering
Etter skriving, les tilbake det flashede bildet og beregn hash-en. Sammenlign med forventet hash. Hvis annerledes, marker enheten som flashing-feil og rut til omarbeiding.
Dette fanger det sjeldne tilfellet hvor selve skrivingen lyktes, men brikken skrev rusk.
Per-enhet-logging
Etter vellykket flash, logg:
- Fastvareversjon
- Fastvare-hash
- Signeringsnøkkelreferanse
- Programmeringstidsstempel
- Per-enhet-serienummer
Disse dataene lever i produksjonens sporbarhetsdatabase. Kjøper kan spørre senere: "hvilken fastvare ble levert på serienummer XXX, signert av hvilken nøkkel".