BLE OTA DFU: Over-the-Air Firmware Updates
Implementing secure wireless firmware updates for BLE devices
BLE OTA DFU: Over-the-Air Firmware Updates
Over-the-Air Device Firmware Update (OTA DFU) lets you push new firmware to deployed BLE devices without physical access. Designing a reliable OTA pipeline is non-negotiable for any IoT product with a production fleet — a bug in the field must be fixable remotely. This guide covers bootloader architecture, image signing, BLE transport protocols, and rollback strategies.
Bootloader Architecture
A robust OTA system requires two separate firmware regions:
+---------------------------+
| Bootloader (protected) | -- never updated OTA
+---------------------------+
| Application Slot A | -- active image
+---------------------------+
| Application Slot B | -- staging slot
+---------------------------+
| Scratch / Data |
+---------------------------+
On reset, the bootloader validates the active slot's signature and jumps to it. During OTA, the new image is written to the staging slot. After a successful transfer and signature verification, the bootloader swaps slots (or marks B as primary) and resets.
| Strategy | Pros | Cons |
|---|---|---|
| Swap (A/B) | Instant rollback possible | Requires 2× app flash |
| Copy (overwrite A from B) | Saves flash | No atomic rollback |
| Direct-XIP | No copy needed | Both slots must be executable |
Nordic nRF5340 / MCUboot: MCUboot is the industry-standard open-source bootloader, integrated into Zephyr RTOS and nRF Connect SDK. It supports ECDSA-P256 or RSA-2048 signing, swap-based upgrades, and confirmed/unconfirmed image states.
Image Signing
Never distribute unsigned firmware. Signing ensures authenticity and prevents malicious firmware injection through a compromised OTA transport.
# Generate signing key (MCUboot)
imgtool keygen -k signing_key.pem -t ecdsa-p256
# Sign firmware image
imgtool sign \
--key signing_key.pem \
--header-size 0x200 \
--align 4 \
--version 1.2.0+0 \
--slot-size 0x60000 \
build/app.bin \
build/app_signed.bin
The signed image includes a TLV (Type-Length-Value) header with version, image hash, and ECDSA signature. The bootloader verifies this before any swap.
BLE OTA Protocols
Nordic DFU (nRF5 SDK / nRF Connect SDK)
Nordic's proprietary DFU protocol uses two GATT services: - DFU Control Point (Write + Notify): sends DFU commands, receives responses - DFU Packet (Write Without Response): streams image data at ~2 kBps (1M PHY) to ~4 kBps (2M PHY)
The nRF Connect mobile app and pc-nrfutil CLI both implement the Nordic DFU initiator side. Custom initiator implementations use the open nrf-dfu protocol spec.
MCUmgr / SMP Protocol
MCUmgr is the Zephyr-native management protocol, transport-agnostic (BLE, UART, UDP). Over BLE it uses the SMP (Simple Management Protocol) service:
| ATT">UUID | Role |
|---|---|
8D53DC1D-1DB7-4CD3-868B-8A527460AA84 |
SMP Service |
DA2E7828-FBCE-4E01-AE9E-261174997C48 |
SMP Characteristic |
mcumgr CLI:
mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name=MyDevice \
image upload build/app_signed.bin
mcumgr --conntype ble --connstring ... image list
mcumgr --conntype ble --connstring ... image confirm <hash>
Silicon Labs OTA (EFR32)
Silicon Labs uses the OTA Bootloader gatt-service/" class="glossary-term-link" data-term="GATT Service" data-definition="Collection of related BLE characteristics." data-category="GATT & ATT">GATT Service profile. The Apploader (resident bootloader partition) receives images via a dedicated GATT characteristic and validates them using GBL (Gecko Bootloader) image format.
Transfer Optimization
| Technique | Gain |
|---|---|
| Use LE 2M PHY | ~2× throughput vs 1M PHY |
| Maximize MTU (512 bytes) | Fewer L2CAP PDUs per image byte |
| Write Without Response | Eliminates per-packet ACK latency |
| Connection Interval 7.5–15 ms | High throughput while OTA active |
| Flow control via window size | Prevents buffer overflow on small targets |
A 256 KB image takes approximately 90 s on 1M PHY with default settings, or 45 s on 2M PHY with MTU=512 and 15 ms CI.
Rollback and Fail-Safe Design
Boot → Validate Slot A signature
OK → Check "revert pending" flag
Set? → Revert to Slot B (previous good image)
No → Jump to Slot A
FAIL → Jump to Slot B (recovery image)
FAIL → Enter DFU-only mode (bootloader advertises DFU service)
A "confirmed" image clears the revert flag on first successful boot. If the new firmware never calls mcumgr image confirm (or Nordic's dfu_target_done()), the bootloader reverts on next reset. This self-healing loop is the single most important reliability feature for field deployments.
Security Checklist
- [ ] ECDSA-P256 (or Ed25519) image signing — never ship with debug key
- [ ] Encrypted image transport (NRF_DFU_BLE_LINK_SECURE = 1 or LESC pairing)
- [ ] Version monotonicity enforced by bootloader (downgrade prevention)
- [ ] Bootloader itself protected against OTA overwrite (hardware write protection on bootloader region)
- [ ] Battery check before accepting OTA (reject if < 20%)
See BLE Product Certification for regulatory implications of post-market firmware updates.
자주 묻는 질문
Yes, our guides range from beginner introductions to advanced topics. Each guide indicates its difficulty level and prerequisites so you can find the right starting point.