HardFault

Under the Hood — How BLE OTA Firmware Updates Actually Work

In our previous episode, we introduced why OTA is critical for BLE-powered consumer devices. Now, we go deeper — exploring how firmware is actually transferred, validated, and installed on a BLE device, with references to real-world products like the Apple Watch, Fitbit trackers, and Alexa-enabled wearables.

Overview of the OTA Execution Flow

Here’s a simplified but accurate technical breakdown of the OTA lifecycle on a BLE device:

[ Mobile App / Host ] → [ BLE Transfer → Device ] → [ Flash Write → Temporary Slot ] 
                      → [ Verify Hash/Signature ] → [ Set Boot Flag ] → [ Reboot & Install ]

This is the common workflow in many production-grade devices, including:

• Apple Watch updates, initiated via the iPhone, where watchOS is downloaded to the phone first and then streamed to the Watch using BLE and Wi-Fi handoff.
• Fitbit Charge series, where firmware updates are sent via the Fitbit app using a proprietary BLE DFU service.
• Amazon Halo and Echo Buds, where BLE is used as the update transport when Wi-Fi is unavailable, and updates are staged incrementally.

Step-by-Step OTA Workflow (With Product References)

1. Update Trigger & Metadata Negotiation

The host (usually a mobile app) checks firmware version:

• Fitbit’s app reads a firmware revision string from the tracker and checks for updates from the Fitbit cloud.
• Apple Watch update checks are tied to iOS system-level updates and happen in the background.

If a newer version is found:

• Metadata like image size, version number, and hash are sent to the device.
• The device decides whether to enter DFU mode.

2. Entering DFU Mode (Device Firmware Update)

Fitbit and Apple Watch use a similar strategy:

• Minimal runtime environment loads.
• Only OTA-specific GATT characteristics are exposed (to reduce surface area for bugs).
• In Apple Watch, the BLE transfer may shift to Wi-Fi if available, but fallback OTA occurs fully over BLE.

For embedded BLE SoCs like STM32WB or Nordic:

• Devices typically reset and enter a dedicated DFU bootloader with write-only OTA capabilities and no main application loaded.

3. Firmware Data Transfer over BLE

BLE is not designed for bulk transfer, so updates are sliced into small packets:

• Fitbit uses a proprietary DFU protocol optimized for its BLE hardware with optional resume support.
• Apple Watch supports delta updates and encrypted transfer — firmware is often compressed and sent incrementally.

Technical Details:

• BLE MTU and DLE (Data Length Extension) increase efficiency.
• Transfer rates: typically ~10-60 KB/s on BLE 4.2+, depending on implementation.
• The device writes these packets into a secondary flash slot (inactive firmware bank).

4. Integrity Verification: Cryptographic Hash + Signature

Real-world examples:

• Fitbit validates firmware using a pre-calculated SHA-256 hash sent with the image.
• Apple Watch firmware is signed by Apple and encrypted; only the device with the correct keys can decrypt and install it.
• Some Alexa devices with BLE-based accessories use a similar scheme — validating the update against an ECC signature and a secure bootloader.

Example firmware header for reference:

typedef struct {
    uint32_t magic;               // Magic number (e.g., 0xAABBCCDD)
    uint32_t version;
    uint32_t firmware_size;
    uint32_t crc32;
    uint8_t  sha256[32];
    uint8_t  signature[64];       // ECC/RSA
} firmware_header_t;

5. Bootloader Handoff & Image Activation

Once verified:

• A boot flag or update status is written to flash or special registers.
• Device reboots.
• The bootloader reads flags and switches to the new firmware slot.

Apple Watch & Fitbit:

• Use dual-slot strategy for seamless rollback.
• They also support staged activation — update is installed but activated only after battery > X%, or idle time is detected.

For embedded BLE devices:

• STM32WB bootloader uses Option Bytes or flash keys.
• Nordic nRF52 uses boot metadata stored in protected UICR or custom flash page.

6. Rollback in Case of Failure

Real products like the Echo Buds or Fitbit Inspire implement:

• Fallback mechanism: If boot verification fails (wrong hash, no boot success heartbeat), bootloader rolls back to the last valid image.
• This logic is triggered based on bootloop detection, startup watchdog failure, or absence of application-ready markers.

BLE Transport Efficiency in Production Devices

BLE OTA implementations often use:

• Sliding window flow control to reduce ACK delay
• Resume support to continue broken updates
• Delta patches to reduce payload size (Apple Watch & Alexa earbuds)

For example:

• Fitbit updates are resilient even with phone movement or partial Bluetooth disconnections.
• Amazon’s Halo Band uses encrypted OTA with reconnection and resend mechanisms based on chunk-level CRC.

Summary Table: BLE OTA in Real Devices