⚡ Firmware Architecture

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

In field-deployed Internet of Things systems, physical access to devices is economically impossible once hardware is embedded in wind turbines, automotive engines, or deep underground pipeline monitors. An Over-The-Air (OTA) firmware update mechanism must be mathematically immune to bricking: no network loss, power brownout, or corrupt binary may leave a device non-functional.

1. Flash Memory Layout: The Dual-Bank (A/B) Topology

Single-bank firmware update architectures (where incoming firmware overwrites the active application directly in-place) represent an unacceptable engineering hazard. A sudden power loss during flash erase operations irreversibly bricks the device.

The Dual-Bank Architecture partitions microcontroller flash into discrete, isolated regions:

+-------------------------------------------------------------+
| 0x08000000 - Secure Bootloader (32 KB - Write Protected)    |
+-------------------------------------------------------------+
| 0x08008000 - Boot Metadata / State Sector (16 KB)           |
+-------------------------------------------------------------+
| 0x0800C000 - Application Bank A (Primary Slot - 480 KB)     |
+-------------------------------------------------------------+
| 0x08084000 - Application Bank B (Secondary Slot - 480 KB)   |
+-------------------------------------------------------------+
| 0x080FC000 - Non-Volatile Storage / NVS (Settings - 16 KB)  |
+-------------------------------------------------------------+
  • Bank A (Active Execution): Currently running validated firmware.
  • Bank B (Staging Slot): Receives incoming chunks over MQTT/HTTP. Device continues full operational service while download proceeds in background.
  • State Sector: Stores atomic state flags: active bank index, firmware versions, image hashes, and boot trial counters.

2. Bootloader State Machine & Handshake Verification

The lifecycle of an update follows a strict, deterministic finite state machine (FSM):

  1. Background Download: Application in Bank A streams binary chunks into Bank B via TLS 1.3, calculating a running SHA-256 digest.
  2. Cryptographic Pre-Validation: Application verifies the ECDSA digital signature appended to Bank B against the vendor public key.
  3. State Flag Update: If signature matches, write boot_target = BANK_B and boot_status = TESTING into the metadata sector.
  4. Controlled Reboot: Application triggers a clean software reset (NVIC_SystemReset() on ARM Cortex-M).
  5. Bootloader Evaluation: Bootloader inspects state sector, arms hardware watchdog, increments trial_count, relocates vector table (SCB->VTOR), and jumps to Bank B.

3. Hardware Watchdog Timers & Automatic Rollback Safeguards

A cryptographically valid binary can still contain severe runtime bugs: unhandled null pointers, memory leaks, or network driver deadlocks.

To guard against silent deadlocks, the bootloader initialises an Independent Watchdog Timer (IWDG) clocked by an internal low-speed oscillator (LSI) independent of the main system clock. The new application must execute its self-test suite:

void main(void) {
    hardware_init();
    network_connect();

    // Perform health diagnostics
    if (run_system_self_test() == DIAGNOSTICS_OK && cloud_handshake() == SUCCESS) {
        // Confirm successful boot to bootloader
        ota_confirm_active_bank();
    } else {
        // System unhealthy: force reset to allow bootloader to roll back
        NVIC_SystemReset();
    }
    
    while(1) {
        feed_watchdog();
        process_telemetry();
    }
}

If the application crashes, enters a HardFault loop, or fails to confirm within the watchdog timeout window, the hardware reset fires. On the subsequent boot, the bootloader observes trial_count > MAX_TRIALS, declares Bank B corrupt, marks Bank A active, and executes an instant zero-downtime rollback.

4. Cryptographic Integrity: SHA-256 & ECDSA Signatures

Security in OTA pipelines requires end-to-end cryptographic authentication:

  • SHA-256 Digest: Verifies physical image integrity, protecting against corrupt flash sectors and bit-rot.
  • ECDSA (NIST P-256 / Ed25519): Verifies image provenance. The build server signs the hash using a protected private key. The bootloader contains the immutable public key burned into hardware OTP (One-Time Programmable) memory or secure element (e.g., Microchip ATECC608B).
  • Anti-Rollback Monotonic Counters: Every binary embeds an incrementing security version. Bootloaders reject validly signed images that possess an older version number, neutralizing malicious downgrade attacks targeting known vulnerabilities.

5. OTA Architecture Comparison Matrix

Architecture Flash Overhead Power-Cut Resilience Rollback Support Downtime during Update
Single-Bank In-Place 1x App Size (Minimal) None (Fatal Bricking) Impossible Extended (Full download duration)
Dual-Bank Internal (A/B) 2x App Size 100% Fail-Safe Instant Hardware Rollback < 500ms (Reboot only)
External SPI Flash Staging 1x Internal + Ext Flash 100% Fail-Safe Bootloader copies from SPI 2 - 5 seconds (Copy phase)

6. Key Engineering Invariants & Flash Longevity

  • Atomic Metadata Flushes: State sector writes must be atomic. Never perform multi-byte writes without CRC checksums. If a brownout occurs mid-write on the state sector, the bootloader must fall back to the last valid verified bank state.
  • NOR Flash Wear Leveling: Internal microcontroller NOR flash typically supports 10,000 to 100,000 erase cycles per sector. Metadata sectors written every boot must alternate across multiple physical flash pages to prevent endurance wear-out.
  • Vector Table Relocation (ARM Cortex-M): When branching from bootloader to application in Bank B, the application must immediately configure SCB->VTOR = 0x08084000 before enabling global interrupts. Failure to relocate VTOR causes ISRs to execute old handlers in Bank A, generating catastrophic HardFault crashes.

7. Differential Binary Delta Patching & In-Place Reconstruction Algorithms

Transmitting complete 1MB to 4MB monolithic firmware binaries over bandwidth-constrained cellular LPWAN (NB-IoT) or satellite connections consumes substantial battery energy and recurring carrier data costs. Differential (Delta) OTA updating slashes payload sizes by transmitting only the mathematical delta between the currently running image and the target release.

Specialized embedded delta algorithms (such as BSDiff or Google Courgette tuned for ARM Thumb-2 instruction sets) generate patch files that often shrink update binaries by 90% to 95% (reducing a 1.2MB image to under 60KB):

  • Pre-Image Verification: Before applying the patch, the bootloader calculates the SHA-256 hash of the active flash bank to verify that the base image exactly matches the delta patch pre-condition.
  • Chunk-Wise In-Place Streaming: The reconstructor reads original blocks from Bank A, applies the differential delta stream stored in external flash or RAM scratch buffers, and writes the synthesized new binary into Bank B block by block.
  • Post-Reconstruction Cryptographic Signoff: Once reconstruction completes, the ECDSA signature embedded within the patch header is evaluated against the fully reconstructed Bank B image. Only upon successful cryptographic verification does the bootloader toggle the active bank pointer.
Robert Baindourov

Written & Architected by Robert Baindourov

Senior IoT Firmware & Edge-Cloud Solutions Architect with 17+ years total experience (15+ years professional architecture). Specializing in bare-metal C/C++, FreeRTOS, Zephyr OS, Embedded Rust, hardware secure elements (ATECC608, TPM 2.0), and high-throughput cloud telemetry pipelines (AWS IoT Core, EMQX, Node.js). Based in Los Angeles, CA.