A bricked field device is the most expensive BLE bug. The MCUboot + MCUmgr combination gives you a rollback path if you use it correctly.
Pieces
- MCUboot: bootloader with two image slots, signature verification and swap with revert.
- MCUmgr / SMP: management protocol with an image-management group; runs over BLE (a dedicated SMP GATT service), serial or UDP.
- Client: a phone app or tool that speaks SMP over BLE (for example the
mcumgrCLI or a vendor device-manager app).
Procedure
- Build a signed image (MCUboot rejects unsigned or wrongly signed images when signature checking is on). Keep the private key out of the repo.
- Upload the image to the secondary slot over SMP. Use a short connection interval, 2M PHY and a large MTU during the upload; restore power-saving parameters afterwards.
- Mark it for test (image "test" command) and reset. MCUboot swaps the images and boots the new one unconfirmed.
- In the new firmware, run a self-test (BLE stack up, sensors respond, can reach whatever it must reach), then confirm the image from firmware (Zephyr:
boot_write_img_confirmed()), or let the client confirm it. - If the device resets before confirmation (crash, watchdog, power loss), MCUboot reverts to the previous image on the next boot.
Pitfalls
- Confirming immediately at startup defeats the rollback. Confirm only after the self-test passes.
- No watchdog: a hung new image never resets, so it never reverts. Enable a hardware watchdog.
- Slot size: the image must fit the slot, including trailer space. Check the partition layout before the first field update.
- Upload interrupted: design the client to resume or restart the upload; don't reset into a half-written slot.
- Security: protect the SMP service (require an authenticated, encrypted BLE connection) or anyone nearby can upload firmware or reset the device.