Over-the-Air (OTA) Firmware Update Architecture

We deployed 500 IoT sensors to a client's factory. Three months later, we found a bug in the sensor calibration code. Without OTA updates, we would have needed to physically visit every sensor, connect a programmer, and flash new firmware. That would have taken weeks.

With OTA updates, we pushed the fix to all 500 devices overnight.

OTA updates are not optional for any serious IoT product. But they are also one of the most dangerous features to implement badly. A failed OTA update can permanently brick a device.

The golden rule: never brick the device

Everything in OTA design comes back to this. Whatever happens — power loss during download, corrupted firmware, network timeout, bad firmware that crashes on boot — the device must always be able to recover.

This means:

• Never overwrite the running firmware until the new firmware is fully downloaded and verified
• Always keep a backup firmware that can be restored
• Always verify firmware integrity before applying it
• Always have a way to roll back if the new firmware fails

The dual-bank architecture

The most reliable approach uses two firmware slots in flash memory:

Flash:
┌──────────────┐
│  Bootloader  │  Never overwritten
├──────────────┤
│   Slot A     │  Currently running firmware
├──────────────┤
│   Slot B     │  New firmware downloaded here
└──────────────┘

The OTA process:

1. 1Download new firmware to Slot B
2. 2Verify the download (CRC check, signature verification)
3. 3Mark Slot B as "pending update" in non-volatile memory
4. 4Reboot
5. 5Bootloader sees the pending update, verifies Slot B again
6. 6Switches to boot from Slot B
7. 7Application confirms successful boot
8. 8If confirmation never comes (device crashes), bootloader rolls back to Slot A

Verifying firmware integrity

Never apply firmware without verifying it. At minimum, check a CRC:

bool VerifyFirmware(uint32_t address, uint32_t size, uint32_t expected_crc) {
    uint32_t calculated = CRC32_Calculate((uint8_t*)address, size);
    return calculated == expected_crc;
}

For security, use cryptographic signatures. Sign the firmware binary with a private key during your build process. The device verifies the signature using a public key burned into read-only memory during manufacturing. An attacker cannot push malicious firmware because they do not have your private key.

Handling interrupted downloads

Network connections drop. Power can fail. Your OTA system must handle interrupted downloads gracefully.

Store download progress in non-volatile memory. When the download resumes, start from where it left off:

typedef struct {
    uint32_t firmware_size;
    uint32_t bytes_received;
    uint32_t expected_crc;
    bool     download_complete;
} OTAState;

// Save to flash after each chunk
Flash_Write(OTA_STATE_ADDRESS, &ota_state, sizeof(OTAState));

The update manifest

Before downloading firmware, the device checks a manifest — a small JSON file on your server that describes the latest firmware version:

{
  "version": "2.1.4",
  "size": 131072,
  "crc32": "0xA3F2B891",
  "url": "https://updates.example.com/firmware-2.1.4.bin",
  "min_version": "1.5.0"
}

The device compares the manifest version to its current version. If the manifest version is newer, it downloads the firmware.

Testing OTA thoroughly

Test every failure scenario before shipping:

• Power loss at 10%, 50%, 90% of download
• Power loss during flash write
• Corrupted firmware (wrong CRC)
• Invalid signature
• New firmware that crashes immediately on boot
• New firmware that crashes after 30 seconds

Each scenario must result in the device recovering to a working state. If any scenario bricks the device, your OTA system is not ready for production.