In-line versus offline
At Energetika-VDS, firmware flashing happens on our line through dedicated programming fixtures. When the customer test plan calls for functional test, the unit moves on to a partner test house with the firmware already loaded. AOI runs in-house on every board; FCT is sourced.
Some manufacturers fold flashing into the same fixture as functional test, so the board is placed once and programming runs first, then test. That works when both steps live in the same building. In our setup, flashing and FCT are physically separated: we run flashing in-line, and the partner test house runs the functional sequence against the just-programmed firmware.
For products without functional test in scope, the flashed board ships after AOI without an additional test gate.
Programming interfaces
The interface to the chip varies by chip family:
- SWD: ARM Cortex-M, low pin count, fast
- JTAG: legacy ARM, FPGA, also debug for many chips
- UART: bootloader-based programming, slower but no extra pins needed
- USB-DFU: USB-capable chips, board acts as a USB device during programming
- I2C, SPI: less common, used for some EEPROMs and secure elements
Most production flashes use SWD for ARM Cortex-M devices and JTAG for older or higher-pin-count parts.
Multi-image programming
A connected device usually has more than one firmware image:
- Bootloader: small, signed, immutable after production
- Application: main firmware, OTA-updatable
- File system: configuration, web assets, certificate store
- Manufacturing partition: per-unit calibration, identity, factory data
Production-side programming writes each image in sequence, in the right partition, with the right signing if applicable.
Signed bootloader chains
A signed bootloader checks the signature of the application before booting it. The bootloader itself is signed by the chip's secure boot mechanism (eFuse-stored hash, ROM-based verification).
Result: an attacker cannot replace the application with arbitrary code, because the bootloader will refuse to boot it. An attacker cannot replace the bootloader, because the chip will refuse to boot an unsigned bootloader.
Production-side, this means:
- Bootloader signing key generated and stored in HSM
- Application signing key generated and stored in HSM
- Production line accesses signing through API, never holds the private key
- eFuse burned to lock the bootloader signature in place
Power-loss tolerance
Programming sequences must tolerate power loss mid-flash. Common pattern: write bootloader first to a fixed location, write application to a separate region, set a "valid" flag in NVS only after verification. If power drops mid-write, the bootloader sees the missing valid flag and falls back to known-good firmware (or refuses to boot, depending on policy).
Verification
After write, read back the flashed image and compute its hash. Compare to expected hash. If different, mark the unit as a flashing failure and route to rework.
This catches the rare case where the write itself succeeded but the chip wrote garbage.
Per-unit logging
After successful flash, log:
- Firmware version
- Firmware hash
- Signing key reference
- Programming timestamp
- Per-unit serial
This data lives in the production traceability database. Buyer can query later: "what firmware shipped on serial XXX, signed by which key".