Memory Schemes for Reliable BLE OTA Updates

Memory Partitioning for OTA in BLE Devices — Strategies from Real Products

In previous episodes, we learned why OTA (Over-The-Air) firmware updates are crucial and how they work in practice. Now let’s go even deeper — into memory partitioning, one of the most critical aspects of building a reliable OTA system.

Whether you’re building a BLE device with 256 KB flash or 4 MB, partitioning your memory the right way will determine:

  • How safely updates can be written,
  • Whether rollback is possible,
  • How secure and resilient your boot process is.

Why Partitioning Matters in OTA

During an OTA update, firmware cannot overwrite itself — it would crash in the middle of flashing. So, we need spare memory where the new image is written first, then activated after reboot.

This leads us to multiple partitioning schemes like:

  • Dual-bank (A/B)
  • Single-bank with swap
  • External flash staging
  • Compressed / delta-patch partitioning

Partition Types (with Flash Map Examples)

Let’s look at real-world strategies from consumer electronics and developer SoCs.


1. Dual-Bank Partitioning (A/B Scheme)

How It Works:

  • Two firmware slots: App Slot A and App Slot B
  • OTA writes to inactive slot
  • On success, bootloader switches to the new one

Benefits:

  • Safe rollback
  • Simple upgrade logic
  • Fast boot

Used In:

  • Fitbit Charge 5
  • STM32WB (custom OTA)
  • Android A/B partitions (for bigger systems)

Flash Map Example:

[ 0x08000000 - 0x08003FFF ] Bootloader (16 KB)
[ 0x08004000 - 0x08023FFF ] App Slot A   (128 KB)
[ 0x08024000 - 0x08043FFF ] App Slot B   (128 KB)
[ 0x08044000 - 0x08044FFF ] Settings / Boot Flags (4 KB)


2. Single-Bank + Swap Strategy

How It Works:

  • Only one app slot
  • OTA writes new firmware to a temporary location
  • On reboot, bootloader swaps the new image into the app slot (often block by block)

Benefits:

  • Less flash needed
  • More complex bootloader logic
  • Requires power failure protection during swap

Used In:

  • MCUBoot with STM32, Nordic
  • Echo Buds (Gen 1), where internal flash is tight

Flash Map Example:

[ 0x08000000 - 0x08003FFF ] Bootloader (16 KB)
[ 0x08004000 - 0x08023FFF ] Application (128 KB)
[ 0x08024000 - 0x08043FFF ] Swap / Temp Area (128 KB)
[ 0x08044000 - 0x08044FFF ] Metadata (4 KB)


3. External Flash Staging

How It Works:

  • OTA image is written to an external SPI flash
  • Verified externally
  • Bootloader copies it into internal flash after reboot

Benefits:

  • Avoids internal memory limits
  • Great for updates > internal flash size

Used In:

  • Wear OS watches
  • Smart speakers with BLE fallback
  • Alexa-compatible gadgets with QSPI flash

4. Delta Update with Patch Partitions

How It Works:

  • Only the changed part of the firmware is sent
  • Patch is stored temporarily
  • Bootloader applies patch to current firmware

Benefits:

  • Very low bandwidth
  • Fast BLE OTA
  • Harder to implement (requires patch engine)

Used In:

  • Apple Watch
  • Oura Ring (Gen 3)
  • Fitbit Premium devices

Reserved Memory Regions

Regardless of OTA style, a few regions are always necessary:

RegionPurpose
Bootloader (RO)Startup logic + OTA handler
Settings/MetadataBoot flags, firmware version, status, CRC
OTA Buffer / StagingTemporary area to hold downloaded firmware
Application Slot(s)Where firmware is executed from

STM32WB Example Partition Table (256 KB Flash)

RegionStart AddressSizePurpose
Bootloader0x0800000016 KBMinimal OTA bootloader
App Slot A0x08004000112 KBRunning app
App Slot B0x08020000112 KBOTA target slot
OTA Metadata0x0803F0004 KBSHA, version, flags
BLE Stack (RO)Option BytesVariesSometimes stored separately

Best Practices for Flash Partitioning

  • ✅ Always reserve space for bootloader logic
  • ✅ Keep application slots aligned to flash erase boundaries (typically 4K or 8K)
  • ✅ Use CRC or SHA256 in metadata to ensure integrity
  • ✅ Use last known good flags for rollback capability
  • ❌ Don’t store persistent settings inside OTA partitions

Flash Partition + Security

Partition layout also affects security:

  • Store bootloader and public key in read-protected region
  • Make metadata tamper-proof (signed headers)
  • Enable readout protection (RDP) for SoCs like STM32 or Nordic

Example: Fitbit devices use encrypted OTA + verified hash stored in a protected flash area. If the metadata doesn’t match post-reboot, update is rejected.


Wrap-up

Designing your memory map is the first step in building a reliable and secure OTA system. With BLE devices often constrained in flash size and power, choosing the right layout — and sticking to proven industry patterns — can make or break your update mechanism.



Leave a comment