Notes / Firmware Design & Quality
Firmware update: changing devices in the field safely
Fixing bugs after release needs an update path. A structure that avoids bricking with A/B slots, signature verification and rollback.
Update paths
| Path | Examples |
|---|---|
| Wired | UART, USB DFU, CAN (vehicle diagnostic tester) |
| Wireless (OTA) | BLE, Wi-Fi, LTE |
What causes a brick
- Power loss during a write
- A corrupted image
- New firmware that boots but cannot communicate, so it cannot be updated again
A safe structure
- A/B slots: leave the running image (A) as it is and write the new image to B
- Verification: integrity with a CRC, origin with a digital signature (blocks firmware made by just anyone)
- Trial boot: the bootloader boots B and leaves it "pending confirmation"
- Confirmation: the new firmware runs its self-checks (communication, sensors) and marks itself confirmed
- Rollback: if there is a reset without confirmation (watchdog and so on), the bootloader goes back to A
Open-source bootloaders such as MCUboot provide this structure.
Also
- An anti-rollback counter that prevents version downgrades
- Dangerous loads such as motors and heaters must be stopped during an update
- Vehicles have a standard procedure for flashing through UDS diagnostic services (see the automotive software subject)