HardFault

Technical Overview of OTA in Consumer BLE Devices

Over-the-Air (OTA) firmware updates are fundamental to the lifecycle of modern consumer electronics, especially for BLE-based devices like smart bands, earbuds, or low-power IoT modules. These devices, often deployed in the field with no direct debugging interface, demand a reliable and secure mechanism for remote firmware upgrades.

In this first technical post of the series, we’ll cover the core principles of OTA for BLE systems and lay the foundation for exploring memory architecture, cryptographic validation, and real-world strategies used in production-grade consumer products.

Why BLE Devices Need OTA — from a System Perspective

Most BLE-based consumer electronics operate with limited interfaces: often just a button or RGB LED. These constraints remove the option for physical firmware access post-deployment.

From an embedded systems point of view, OTA becomes essential because:

• Firmware may need updates due to bugs, regulatory changes, or new features.
• Recall and replacement is not scalable.
• BLE SoCs often lack file systems, external flash, or traditional boot media — OTA updates must be carefully engineered into the flash layout.

Core OTA Workflow (BLE-Based System)

Here’s a breakdown of the OTA process commonly implemented in BLE devices:

1. Firmware Discovery

• The device or a connected app initiates a version check via BLE characteristic (e.g., 0x2A26 – Firmware Revision String).
• Update metadata includes version number, size, expected CRC/hash, and sometimes signature.

2. Firmware Transfer Over BLE

• BLE GATT is used for transfer, often via a proprietary DFU service.
• Firmware is sliced into packets (typically 20–244 bytes depending on MTU).
• Transfer is stateful and supports retries, checksums, and progress tracking.
• The target writes to a temporary region in flash (often a secondary slot).

3. Integrity Verification

• Common methods include CRC16/CRC32, or a SHA-256 hash check over the full image.
• Optionally, a digital signature is validated (public key stored on device).
• Verification occurs before install and sometimes again at boot.

4. Flashing and Activation

• Bootloader copies new image to active slot or switches boot vector (depending on single or dual-bank setup).
• Metadata flags in protected flash or option bytes determine boot behavior.
• Device reboots into new firmware if all checks pass.

5. Rollback (if needed)

• If CRC/hash fails or the app crashes on boot, bootloader may restore the last known good image.
• This requires maintaining dual-image storage or an additional rescue/boot recovery region.

BLE-Specific OTA Challenges

OTA over BLE differs significantly from Wi-Fi or USB-based updates:

For example, Nordic’s SoftDevice DFU handles this via a stateful update protocol using a custom BLE service. STM32WB uses a similar method via STM BLE OTA library, leveraging a basic GATT service that the mobile app communicates with.

Real-World Implementations

Many production BLE devices use a minimal bootloader with a small OTA stack (often <16KB), and reserve a secondary flash partition for OTA transfer.

Typical flash layout for dual-bank update (STM32WB/Nordic-style):

|-------------| 0x08000000
| Bootloader  | (protected region)
|-------------| 0x08004000
| App Slot A  |
|-------------| 0x08020000
| App Slot B  |
|-------------| 0x0803F000
| OTA Flags / Metadata |

This allows:

• One image to run while the other is updated
• Bootloader to swap partitions on next boot
• Rollback if new image fails verification

BLE OTA Protocols in Practice

Some popular BLE OTA protocols used in real devices:

• Nordic Secure DFU
  Based on BLE GATT + signed firmware + stateful update service
• Dialog DA145xx SUOTA
  Transfer firmware in chunks via BLE service; writes to external SPI flash or internal flash
• STM32WB OTA
  Uses custom BLE services in STM32Cube BLE stack; app triggers OTA and sets flags for bootloader