In-line versus offline
In-line flashing happens at the functional test station. The test fixture also acts as the programming fixture. The board is placed on the fixture once: programming runs first, then test runs against the just-programmed firmware. Saves cycle time.
Offline flashing uses a dedicated programmer fixture, separate from test. The board is preprogrammed in bulk before reaching the test station. Useful when test cycle time is short and programming time is long, or when programming requires a separate environment (high voltage, special cabling).
For most connected products, in-line is the default.
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".