In-line versus offline
Az Energetika-VDS-nél a firmware flashelés a gyártósorunkon történik dedikált programozási fixtúrákon keresztül. Amikor az ügyfél tesztterve funkcionális tesztet ír elő, a darab partner tesztházhoz kerül a már betöltött firmware-rel. Az AOI minden panelen házon belül fut; az FCT-t kihelyezzük.
Néhány gyártó a flashelést ugyanabba a fixtúrába integrálja, mint a funkcionális tesztet, így a panel egyszer kerül elhelyezésre, először a programozás fut, majd a teszt. Ez akkor működik, ha mindkét lépés ugyanabban az épületben van. A mi felállásunkban a flashelés és az FCT fizikailag elkülönül: a flashelést in-line végezzük, és a partner tesztház futtatja a funkcionális szekvenciát az éppen programozott firmware-rel.
Olyan termékek esetén, ahol a funkcionális teszt nem része a feladatkörnek, a flashelt panel az AOI után kiszállításra kerül további tesztkapu nélkül.
Programozási interfészek
A chiphez vezető interfész a chip családjától függ:
- SWD: ARM Cortex-M, kis lábszám, gyors
- JTAG: legacy ARM, FPGA, debug is sok chiphez
- UART: bootloader-alapú programozás, lassabb, de nem igényel extra lábakat
- USB-DFU: USB-képes chipek, a panel USB eszközként viselkedik a programozás során
- I2C, SPI: kevésbé gyakori, néhány EEPROM-hoz és secure elementhez használt
A legtöbb gyártási flashelés SWD-t használ ARM Cortex-M eszközökhöz és JTAG-et régebbi vagy nagyobb lábszámú alkatrészekhez.
Több image programozás
Egy connected device általában több firmware image-dzsel rendelkezik:
- Bootloader: kicsi, aláírt, gyártás után megváltoztathatatlan
- Alkalmazás: fő firmware, OTA-frissíthető
- Fájlrendszer: konfiguráció, web assetek, tanúsítványtár
- Manufacturing partíció: darabonkénti kalibráció, identitás, gyári adatok
A gyártás oldali programozás minden image-et sorrendben ír, a megfelelő partícióba, megfelelő aláírással, ha alkalmazható.
Aláírt bootloader láncok
Egy aláírt bootloader ellenőrzi az alkalmazás aláírását bootolás előtt. Magát a bootloadert a chip biztonságos boot mechanizmusa írja alá (eFuse-ban tárolt hash, ROM-alapú ellenőrzés).
Eredmény: a támadó nem helyettesítheti az alkalmazást tetszőleges kóddal, mert a bootloader nem fogja bootolni. A támadó nem helyettesítheti a bootloadert, mert a chip nem fog elindítani aláíratlan bootloadert.
Gyártás oldalon ez azt jelenti:
- Bootloader aláíró kulcs generálva és HSM-ben tárolva
- Alkalmazás aláíró kulcs generálva és HSM-ben tárolva
- A gyártósor API-n keresztül fér hozzá az aláíráshoz, soha nem birtokolja a privát kulcsot
- eFuse beégetve a bootloader aláírás rögzítéséhez
Áramkimaradás tűrés
A programozási szekvenciáknak tűrniük kell az áramkimaradást flashelés közben. Gyakori minta: bootloader írása először egy rögzített helyre, alkalmazás írása külön régióba, "valid" flag beállítása az NVS-ben csak ellenőrzés után. Ha az áram megszakad írás közben, a bootloader látja a hiányzó valid flaget, és visszaáll ismert jó firmware-re (vagy nem indít el, a házirendtől függően).
Ellenőrzés
Írás után olvassa vissza a flashelt image-et és számítsa ki a hash értékét. Hasonlítsa össze a várt hash-sel. Ha eltér, jelölje meg a darabot flashelési hibásként, és irányítsa át újragyártásra.
Ez elkapja azt a ritka esetet, amikor az írás sikerült, de a chip szemetet írt.
Darabonkénti naplózás
Sikeres flashelés után naplózzon:
- Firmware verzió
- Firmware hash
- Aláíró kulcs referencia
- Programozás időbélyegzője
- Darabonkénti sorozatszám
Ez az adat a gyártási nyomonkövethetőségi adatbázisban él. A vevő később lekérdezheti: "milyen firmware-rel szállították az XXX sorozatszámú darabot, melyik kulccsal aláírva".