In-line versus offline
La Energetika-VDS, programarea firmware-ului se face pe linia noastră prin fixturi de programare dedicate. Când planul de testare al clientului prevede testare funcțională, unitatea trece la o casă parteneră de testare cu firmware-ul deja încărcat. AOI rulează in-house pe fiecare placă; FCT este externalizat.
Unii producători combină programarea în aceeași fixtură cu testarea funcțională, astfel încât placa este așezată o singură dată, iar programarea rulează prima, apoi testarea. Funcționează când ambii pași sunt în aceeași clădire. În configurația noastră, programarea și FCT sunt separate fizic: rulăm programarea in-line, iar casa parteneră de testare rulează secvența funcțională pe firmware-ul tocmai programat.
Pentru produse fără testare funcțională în domeniul de aplicare, placa programată este livrată după AOI fără o etapă suplimentară de testare.
Interfețe de programare
Interfața cu chip-ul variază în funcție de familia de chip-uri:
- SWD: ARM Cortex-M, număr mic de pini, rapid
- JTAG: ARM legacy, FPGA, dar și debug pentru multe chip-uri
- UART: programare bazată pe bootloader, mai lentă, dar fără pini suplimentari
- USB-DFU: chip-uri capabile de USB, placa acționează ca dispozitiv USB în timpul programării
- I2C, SPI: mai puțin frecvente, folosite pentru unele EEPROM-uri și elemente securizate
Cele mai multe programări de producție folosesc SWD pentru dispozitivele ARM Cortex-M și JTAG pentru piesele mai vechi sau cu număr mai mare de pini.
Programare multi-imagine
Un dispozitiv conectat are de obicei mai mult de o imagine de firmware:
- Bootloader: mic, semnat, imutabil după producție
- Aplicație: firmware-ul principal, actualizabil OTA
- Sistem de fișiere: configurație, resurse web, depozit de certificate
- Partiție de producție: calibrare per unitate, identitate, date de fabrică
Programarea pe partea de producție scrie fiecare imagine în secvență, în partiția corectă, cu semnătura corectă, dacă este cazul.
Lanțuri de bootloader semnate
Un bootloader semnat verifică semnătura aplicației înainte de a o porni. Bootloaderul însuși este semnat prin mecanismul de secure boot al chip-ului (hash stocat în eFuse, verificare bazată pe ROM).
Rezultat: un atacator nu poate înlocui aplicația cu cod arbitrar, deoarece bootloaderul va refuza să o pornească. Un atacator nu poate înlocui bootloaderul, deoarece chip-ul va refuza să pornească un bootloader nesemnat.
Pe partea de producție, asta înseamnă:
- Cheia de semnare a bootloaderului generată și stocată în HSM
- Cheia de semnare a aplicației generată și stocată în HSM
- Linia de producție accesează semnarea prin API, nu deține niciodată cheia privată
- eFuse ars pentru a bloca semnătura bootloaderului
Toleranța la pierderea de tensiune
Secvențele de programare trebuie să tolereze pierderea de tensiune la jumătatea flash-ului. Tipar frecvent: scriere bootloader mai întâi într-o locație fixă, scriere aplicație într-o regiune separată, setare flag "valid" în NVS doar după verificare. Dacă se pierde tensiunea în timpul scrierii, bootloaderul vede flag-ul valid lipsă și revine la firmware-ul cunoscut ca bun (sau refuză să pornească, în funcție de politică).
Verificare
După scriere, citiți înapoi imaginea programată și calculați hash-ul acesteia. Comparați cu hash-ul așteptat. Dacă diferă, marcați unitatea ca eșec de programare și rutați la rework.
Acest lucru prinde cazul rar în care scrierea în sine a reușit, dar chip-ul a scris date corupte.
Înregistrare per unitate
După programarea reușită, înregistrați:
- Versiunea firmware-ului
- Hash-ul firmware-ului
- Referința cheii de semnare
- Marcaj temporal al programării
- Serie per unitate
Aceste date trăiesc în baza de date de trasabilitate a producției. Cumpărătorul poate interoga ulterior: "ce firmware a fost livrat pe seria XXX, semnat cu ce cheie".