Iotsoftwaredeveloper Inc.

Iotsoftwaredeveloper Inc.

💻 Tech & Development & Professional Digital Portal

⚡ Firmware Architecture

Designing Resilient Over-The-Air (OTA) Firmware Updates: Dual-Bank Architecture

Deploying connected microcontrollers to the field without a bulletproof Over-The-Air (OTA) firmware update system is an unacceptable operational risk. In remote industrial installations, a single corrupted firmware flash can brick thousands of inaccessible devices, resulting in catastrophic maintenance costs. This guide details the design and implementation of a fail-safe Dual-Bank A/B flash partitioning architecture with cryptographic verification and autonomous watchdog rollbacks.

1. Flash Memory Partition Layout (Dual-Bank A/B)

To guarantee uninterrupted device availability, internal or external flash memory is partitioned into symmetrical slots:

Partition Slot Address Range Purpose & Access Controls
Stage 1 Bootloader 0x08000000 - 0x08007FFF Immutable, write-protected hardware bootloader. Performs image validation and bank switching.
Slot A (Primary App) 0x08008000 - 0x0807FFFF Currently running production firmware binary.
Slot B (Secondary App) 0x08080000 - 0x080FFFFF Target staging slot for incoming OTA firmware chunks.
NVRAM / Scratch Area 0x08100000 - 0x08103FFF Boot flags, execution counters, rollback counters, and cryptographic public keys.

2. The Five-Phase Safe OTA Lifecycle

  1. Transport & Chunked Download: The running application downloads the firmware binary in 512-byte signed chunks via MQTT or HTTPS/TLS, staging them directly into Slot B.
  2. Cryptographic Header Validation: Before altering boot flags, the SHA-256 digest of the entire image is computed and verified against an Ed25519 digital signature embedded in the firmware header.
  3. Tentative Boot Marking: The bootloader updates the NVRAM metadata flag to BOOT_TENTATIVE_SLOT_B and reboots the MCU.
  4. Application Self-Test & Confirmation: Upon first boot, the new firmware initializes hardware peripherals, connects to the cloud, and marks itself BOOT_CONFIRMED.
  5. Autonomous Watchdog Rollback: If the new image faults, hangs in an infinite loop, or fails to assert the confirmation flag before the hardware watchdog timer expires, the Stage 1 bootloader automatically reverts the active slot pointer back to Slot A.

Hardware Root of Trust Recommendation

Never rely on software-based checksums (such as CRC32) for firmware validation. Always enforce asymmetric public key verification (Ed25519 or ECDSA Secp256r1) stored in read-only hardware fuses or a dedicated Secure Element (e.g., ATECC608B).

Robert Baindourov

Written & Architected by Robert Baindourov

Senior Embedded Systems & IoT Firmware Architect with 15+ years of production experience in bare-metal C/C++, FreeRTOS, wireless mesh protocols, and high-throughput industrial telemetry backends.