In-line наспроти offline
Во Energetika-VDS, flashing-от на firmware се случува на нашата линија преку наменски програмски fixtures. Кога test plan-от на клиентот бара функционален тест, единицата се пренесува до партнерска тест куќа со веќе вчитан firmware. AOI работи во-куќа на секоја плоча; FCT е извор.
Некои производители го споиваат flashing-от во истиот fixture со функционалниот тест, така што плочата се поставува еднаш и програмирањето оди прво, потоа тест. Тоа функционира кога двата чекори се во истата зграда. Во нашиот setup, flashing-от и FCT се физички одвоени: ние го извршуваме flashing-от in-line, а партнерската тест куќа ја извршува функционалната секвенца против штотуку програмираниот firmware.
За производи без функционален тест во опсегот, програмираната плоча се испраќа после AOI без дополнителна тест порта.
Програмски интерфејси
Интерфејсот до чипот варира по фамилија на чипови:
- SWD: ARM Cortex-M, мал број на pin, брзо
- JTAG: legacy ARM, FPGA, исто така debug за многу чипови
- UART: програмирање базирано на bootloader, побавно но не се потребни дополнителни pin
- USB-DFU: чипови способни за USB, плочата се однесува како USB уред за време на програмирање
- I2C, SPI: помалку чести, се користат за некои EEPROM и безбедни елементи
Повеќето производствени flash-еви користат SWD за ARM Cortex-M уреди и JTAG за постари или делови со поголем број pin.
Multi-image програмирање
Поврзан уред обично има повеќе од една firmware слика:
- Bootloader: мал, потпишан, непроменлив по производство
- Application: главен firmware, OTA-достапен за ажурирање
- File system: конфигурација, web ресурси, certificate store
- Manufacturing partition: по-единечна калибрација, идентитет, фабрички податоци
Производственото програмирање ја запишува секоја слика по редослед, во правилниот партиција, со правилно потпишување доколку е применливо.
Потпишани bootloader chains
Потпишан bootloader го проверува потписот на апликацијата пред да ја подигне. Самиот bootloader е потпишан од безбедниот boot механизам на чипот (eFuse-чуван хеш, ROM-базирана верификација).
Резултат: напаѓач не може да ја замени апликацијата со произволен код, бидејќи bootloader-от ќе одбие да ја подигне. Напаѓач не може да го замени bootloader-от, бидејќи чипот ќе одбие да подигне непотпишан bootloader.
На производствена страна, ова значи:
- Bootloader потписниот клуч генериран и зачуван во HSM
- Application потписниот клуч генериран и зачуван во HSM
- Производната линија пристапува до потпишување преку API, никогаш не го држи приватниот клуч
- eFuse изгорена за да го заклучи потписот на bootloader-от на место
Толеранција на загуба на енергија
Програмските секвенци мора да толерираат загуба на енергија среде flash. Чест шаблон: запишете го bootloader-от прво на фиксна локација, запишете ја апликацијата во посебна област, поставете "valid" знаме во NVS само по верификација. Ако енергијата падне среде запис, bootloader-от го гледа отсутниот valid знаме и се враќа на познат-добар firmware (или одбива да подигне, во зависност од политика).
Верификација
После запис, прочитајте ја flash-ираната слика и пресметајте го нејзиниот хеш. Споредете со очекуваниот хеш. Ако е различен, означете ја единицата како дефект при flashing и насочете до rework.
Ова го фаќа ретокот случај каде самиот запис успеа но чипот запишал ѓубре.
По-единечно logging
После успешен flash, запишете:
- Firmware верзија
- Firmware хеш
- Референца на потписниот клуч
- Временска ознака на програмирање
- По-единечен сериски
Овие податоци живеат во производната traceability база. Купувачот може подоцна да побара: "кој firmware е испратен на сериски XXX, потпишан со кој клуч".