Bootloader Architecture for Over-The-Air (OTA) Firmware Updates

The deployment of Internet of Things (IoT) connected devices has radically transformed how we conceive of the hardware lifecycle. Previously, an electronic device came off the production line with static firmware that was rarely, if ever, modified. Today, the ability to remotely deliver security patches, fix bugs, and add new features is not a luxury, but a fundamental requirement. However, this power comes with a significant risk: a power outage, a communication error, or a corrupted image during a remote update can render the device inoperable, a state colloquially known as a "dead device." ""bricking"". To mitigate this risk, the industry relies on a critical and often underestimated piece of software: the bootloader.

A robust bootloader design is the cornerstone of any successful Over-The-Air (OTA) update strategy. Unlike application code, which can fail and be restarted, a catastrophic failure of the bootloader or the update process it manages typically requires physical intervention, defeating the purpose of remote updates and incurring prohibitive logistical costs. In this article, we will explore modern bootloader architecture, memory partitioning strategies, failover mechanisms, and the essential security considerations for keeping IoT device fleets updated and operational in the field.

The Critical Role of the Bootloader in the Boot Cycle

A bootloader is a small, highly specialized program that resides in a fixed location in the microcontroller's non-volatile memory (typically at the flash memory's home address, such as 0x08000000 (in STM32 architectures). It is the first piece of code that executes when the device receives power or exits a reset state. Its primary responsibility is to establish a safe and predictable execution environment before handing control over to the main application.

The fundamental functions of a bootloader include initializing the minimum necessary hardware (such as configuring the system clock and stack pointer), verifying the integrity of the memory-resident application image, and deciding whether to execute that application or enter update mode to receive new firmware. Due to its privileged position in the boot sequence, the bootloader has absolute control over the device. For this reason, its code must be as simple and deterministic as possible, minimizing the attack surface and the probability of logical errors.

In modern embedded systems, the bootloader size typically ranges between 16 KB and 32 KB, This depends on the complexity of the supported communication protocols and the implemented cryptographic verification routines. It is a recommended practice that the bootloader itself not be updatable over the air (OTA), as a failure during the update invariably results in a remotely unrecoverable device.

Memory Architecture: Partitioning Strategies

The way the microcontroller's flash memory is organized directly dictates the resilience of the upgrade process. There are two main approaches: single-bank architecture and dual-bank architecture (also known as A/B slots).

Single-Bank Architecture

In a single-bank design, the flash memory is simply divided into two regions: one for the bootloader and one for the application. When an over-the-air (OTA) update is received, the bootloader must erase the existing application and write the new image in its place. This approach maximizes the space available for the application but lacks redundancy. If a power loss or transmission error occurs during the erase or write process, the device is left without a valid application to run, resulting in a critical failure. This design is only acceptable on devices where manual recovery is trivial or where extreme cost constraints prevent the use of microcontrollers with larger memory capacities.

Dual-Bank Architecture (A/B Slots)

For robust OTA deployments, the Dual-Bank architecture is the industry standard. In this model, the flash memory allocated to the application is divided into two identical partitions, commonly referred to as Slot A (Primary) and Slot B (Secondary). Slot A contains the known and functional firmware that the device normally runs. When an OTA update is initiated, the new firmware image is downloaded and written to Slot B in the background, while the current application continues running in Slot A.

Table 1: Typical memory distribution in a Dual-Bank A/B architecture.

Once the download is complete and the integrity of the image in Slot B is verified, the device reboots. The bootloader detects the presence of a new, valid image and proceeds to activate it. The critical advantage of this architecture is that if the update fails at any point before final activation, the original firmware in Slot A remains intact, ensuring that the device always has a safe recovery state.

Rollback Mechanisms and Bricking Prevention

Even if a firmware image is downloaded successfully and passes cryptographic integrity checks, there is no guarantee that the code is free of logical errors that could prevent the device from functioning normally (for example, an infinite loop during initialization or a failure to connect to the network). To protect against these eventualities, advanced bootloaders implement mechanisms of Rollback (reversion).

The most effective pattern for managing rollback is the rollback model ""Commit"" or test mode. When the bootloader boots a new firmware image for the first time, it marks it as "pending" or "in test." The responsibility then falls to the new application to perform its initialization routines, verify network connectivity, and, if everything works correctly, write a confirmation flag to non-volatile memory to indicate that the update was successful.

If the new application fails and crashes before success can be confirmed, a Hardware Watchdog Timer (WDT) The Watchdog Timer (WDT), configured by the bootloader before the application jumps, will intervene. It will force a system reboot if it is not periodically "fed." Upon reboot, the bootloader will detect that the test image was not committed and will automatically revert to the previous known and functional firmware. It is recommended to set the Watchdog timeout to between 2 and 3 times the expected application initialization time (typically around 10 seconds). 2 to 5 seconds (for industrial controllers) to avoid false positives.

Cryptographic Integrity and Security Verification

Security is the most critical aspect of any OTA system. An update mechanism without proper protection is an open backdoor for malicious actors to inject compromised firmware, take control of the device fleet, or extract intellectual property. Bootloader security relies on rigorously verifying the integrity and authenticity of each firmware image before execution.

While cyclic redundancy checks (CRC-32) are useful for detecting accidental corruption during data transmission, they offer no protection against intentional manipulation. To guarantee authenticity, the use of asymmetric digital signatures.

In a secure workflow, the firmware is signed on the manufacturer's servers using a strongly protected private key. The embedded device stores the corresponding public key (ideally in OTP — One-Time Programmable Memory, or a hardware Secure Element), and the bootloader uses this key to verify the signature of the downloaded image. The algorithm ECDSA (Elliptic Curve Digital Signature Algorithm) with the P-256 curve It is widely recommended in the industry due to its excellent balance between robust security and computational efficiency, requiring signatures of only 64 bytes and verification times of approximately 50 milliseconds on a microcontroller operating at 120 MHz.

In addition to authentication, it is crucial to implement mechanisms Anti-Rollback. An attacker could attempt to load an older, legitimate version of the firmware that contains known security vulnerabilities. To prevent this, the bootloader must maintain a minimum acceptable version counter in persistent storage and reject any image with a lower version number, regardless of whether its cryptographic signature is valid.

OTA Communication Protocols

The choice of wireless communication protocol for over-the-air (OTA) updates depends largely on the deployment environment, power constraints, and firmware size. Each technology presents unique challenges that the update system must manage.

For network-connected devices Wi-Fi, Bandwidth is generally not a limiting factor. Updates can be downloaded quickly using standard protocols such as HTTPS, facilitating integration with existing cloud infrastructures. However, power consumption during Wi-Fi transmission is considerable (~250 mA), requiring battery-powered devices to check their charge level before initiating an update.

In the case of devices that use Bluetooth Low Energy (BLE), For devices such as wearables or portable medical sensors, power consumption is drastically lower (~12 mA), but the transfer speed is reduced to between 125 Kbps and 2 Mbps (BLE 5.0). Specific protocols such as Nordic Semiconductor's Device Firmware Update (DFU) are optimized to handle packet fragmentation and the resumption of interrupted transfers.

For low-power wide area networks (LPWANs) such as LoRaWAN, Over-the-air (OTA) updates present a monumental challenge. With transfer speeds that can be as low as 0.3 Kbps and strict restrictions on duty cycles, sending a complete firmware image is impractical. In these scenarios, strategies are employed to Delta Updates, where the server calculates the exact difference between the current and new firmware, and transmits only that differential patch.

The Role of Pre-Programming in Mass Production

Although the ultimate goal is to manage the software lifecycle remotely, every device must begin its existence with a reliable codebase. This initial process, known as pre-programming or factory programming, is where the root of trust of the hardware is established.

During mass production, blank microcontrollers are programmed using high-speed automated equipment (Gang programmers) before being soldered to the printed circuit board (PCB). At this critical stage, the immutable bootloader, the initial firmware image, is injected into Slot A, and fundamental security parameters are configured. This includes writing the cryptographic public keys to the OTP memory and enabling hardware security locks, such as disabling the JTAG/SWD debug ports (JTAG Lockout) to prevent unauthorized memory access.

A faulty or insecure initial program irreparably compromises the device's ability to securely receive future over-the-air (OTA) updates. Therefore, the integration between the bootloader design and electronic manufacturing processes must be seamless, ensuring that every chip leaving the production line possesses a unique cryptographic identity and a validated update mechanism.

SBC Group Connection: Secure Volume Bootloader Programming

At SBC Group, we understand that the security and reliability of your IoT devices in the field begins on the production line. Our high-volume integrated circuit programming services are designed to support the most demanding bootloader architectures. We utilize state-of-the-art automated programming systems that guarantee the accurate injection of the bootloader, initial firmware, and unique cryptographic keys for each device.

We implement strict protocols for JTAG lockout and OTP memory management, ensuring that your hardware's root of trust is established in an inviolable manner before the component is assembled onto the PCB. By partnering with SBC Group, you ensure your OTA update strategy has a solid foundation from day one, minimizing the risk of field failures and protecting your intellectual property.

Learn more

To learn more about bootloader architectures and best practices for OTA updates, we recommend consulting the following technical resources:

• Official MCUboot DocumentationThe open-source standard for secure bootloaders on 32-bit microcontrollers, with support for Dual-Bank architectures and cryptographic verification.
• SBC Group Microcontroller Programming ServicesDiscover how our volume programming capabilities can ensure the initial injection of your bootloader and security keys.
• Bootloader Design Guide for Field UpgradesA detailed analysis of design patterns, state management, and power failure recovery.

References: [1] Salitronic, "Bootloader Design for Reliable Field Updates," 2026. [2] Industrial Monitor Direct, "Designing A/B Firmware Slots in Embedded Bootloaders," 2026.