In-line versus offline
Presso Energetika-VDS, il flashing del firmware avviene sulla nostra linea attraverso fixture di programmazione dedicate. Quando il piano di test del cliente richiede un functional test, l'unità si sposta in un laboratorio di test partner con il firmware già caricato. L'AOI viene eseguita internamente su ogni scheda; l'FCT è esternalizzato.
Alcuni produttori integrano il flashing nella stessa fixture del functional test, in modo che la scheda venga posizionata una sola volta e la programmazione avvenga per prima, poi il test. Questo funziona quando entrambi i passaggi sono nello stesso edificio. Nella nostra configurazione, flashing e FCT sono fisicamente separati: eseguiamo il flashing in linea, e il laboratorio di test partner esegue la sequenza funzionale sul firmware appena programmato.
Per prodotti senza functional test in scopo, la scheda con firmware spedisce dopo l'AOI senza un ulteriore gate di test.
Interfacce di programmazione
L'interfaccia verso il chip varia per famiglia:
- SWD: ARM Cortex-M, basso numero di pin, veloce
- JTAG: ARM legacy, FPGA, anche debug per molti chip
- UART: programmazione basata su bootloader, più lenta ma senza pin aggiuntivi
- USB-DFU: chip USB-capable, la scheda funge da dispositivo USB durante la programmazione
- I2C, SPI: meno comune, usato per alcune EEPROM ed elementi sicuri
La maggior parte dei flashing in produzione usa SWD per dispositivi ARM Cortex-M e JTAG per componenti più vecchi o con maggiore numero di pin.
Programmazione di immagini multiple
Un dispositivo connesso ha solitamente più di un'immagine firmware:
- Bootloader: piccolo, firmato, immutabile dopo la produzione
- Applicazione: firmware principale, aggiornabile via OTA
- File system: configurazione, asset web, archivio certificati
- Partizione di produzione: calibrazione per unità, identità, dati di fabbrica
La programmazione lato produzione scrive ogni immagine in sequenza, nella partizione corretta, con la firma corretta se applicabile.
Catene di bootloader firmati
Un bootloader firmato verifica la firma dell'applicazione prima di avviarla. Il bootloader stesso è firmato dal meccanismo di secure boot del chip (hash memorizzato in eFuse, verifica basata su ROM).
Risultato: un attaccante non può sostituire l'applicazione con codice arbitrario, perché il bootloader rifiuterà di avviarlo. Un attaccante non può sostituire il bootloader, perché il chip rifiuterà di avviare un bootloader non firmato.
Lato produzione, questo significa:
- Chiave di firma del bootloader generata e conservata in HSM
- Chiave di firma dell'applicazione generata e conservata in HSM
- La linea di produzione accede alla firma tramite API, non possiede mai la chiave privata
- eFuse bruciato per bloccare la firma del bootloader in posizione
Tolleranza alla perdita di alimentazione
Le sequenze di programmazione devono tollerare la perdita di alimentazione a metà flashing. Pattern comune: scrivere prima il bootloader in una posizione fissa, scrivere l'applicazione in una regione separata, impostare un flag "valido" in NVS solo dopo la verifica. Se l'alimentazione cade a metà scrittura, il bootloader vede il flag mancante e ricade su firmware noto-buono (o rifiuta di avviarsi, a seconda della policy).
Verifica
Dopo la scrittura, rileggete l'immagine flashata e calcolatene l'hash. Confrontate con l'hash atteso. Se differisce, marcate l'unità come fallimento di flashing e indirizzatela alla rilavorazione.
Questo cattura il raro caso in cui la scrittura stessa ha avuto successo ma il chip ha scritto dati corrotti.
Logging per unità
Dopo un flashing riuscito, registrate:
- Versione del firmware
- Hash del firmware
- Riferimento della chiave di firma
- Timestamp di programmazione
- Numero di serie per unità
Questi dati risiedono nel database di tracciabilità di produzione. Il buyer può interrogare in seguito: "quale firmware è stato spedito sul seriale XXX, firmato con quale chiave".