Firmware updates are one of the places where an embedded prototype either becomes maintainable or becomes expensive to support. The hard part is not moving a binary from a laptop to a board. The hard part is making the whole path controlled, observable and recoverable when the device is in the field.
This internal R&D project explores that path on a Nordic nRF5340-DK. It uses Bluetooth Low Energy for a local maintenance connection, Zephyr and the nRF Connect SDK for the firmware base, MCUmgr SMP for management transport and MCUboot for verified boot and recovery.
Why use BLE for an OTA workflow?
Many embedded products are installed where permanent Internet access is not available, desirable or reliable. A technician may still be able to stand next to the device with a laptop or phone. BLE provides a practical local channel for commissioning, diagnostics and controlled updates without adding a cloud dependency simply for maintenance.
For that to be useful, the update flow needs more than a file picker. Before the upload, the operator should be able to identify the device and inspect its current firmware and diagnostic state. During the upload, the target should enforce its own policy. After reboot, the system must know whether the new image is actually healthy.
The update path
The browser dashboard uses Web Bluetooth to connect to the nRF5340-DK. The device exposes identity, version and diagnostic information, then accepts an approved firmware package over MCUmgr SMP carried by Bluetooth LE.
The uploaded image is written to the secondary slot. On the next reboot, MCUboot validates it and starts it as a test image. The application runs its defined startup checks and explicitly confirms the image only after it is operational. If confirmation never happens, MCUboot restores the previous known-good image on the following reboot.
That sequence creates a simple but important distinction:
- an image can be transferred;
- an image can be allowed to boot;
- an image can be confirmed as healthy.
Treating those as separate states is what makes field recovery possible.
Signing and version policy
The prototype signs firmware images with ECDSA P-256. MCUboot verifies the signature against the public key in the boot chain before a candidate image is executed. A BLE connection alone is therefore not enough to make an arbitrary binary runnable.
The update policy also checks release metadata to prevent unsafe downgrades. The exact product rules can differ, but the principle is consistent: the target device must decide whether a package is appropriate for its hardware, software generation and operating state.
For normal operation, update access can be limited through a timed service mode. The device enables maintenance for a defined period, then closes it again automatically. This keeps the control near the target instead of relying entirely on the dashboard to behave correctly.
Dual-core nRF5340 design
The nRF5340 provides an application core and a network core. In this project, the application core owns the device logic, update policy and diagnostics, while the network core supports Bluetooth LE connectivity. The split is useful because it makes firmware responsibilities visible early, before more product-specific functions are added.
The development kit is not the final product, but it is the right place to test the interaction between flash layout, bootloader configuration, radio transfer and application startup. Those details are difficult to validate with desktop tooling alone.
What physical-hardware testing changed
The demo update sequence was verified on a real nRF5340-DK with signed releases from 1.0.11 to 1.0.14. The tests covered BLE transfer, boot behavior, version controls, image confirmation and automatic rollback.
The key lesson is that OTA is a system feature. The browser interface, BLE transport, MCUboot slots, firmware startup checks and service procedure all have to agree. A robust implementation is less about one clever component than about making the failure states explicit and recoverable.
Moving from a demo to a product
A production adaptation needs dedicated signing keys, secure key handling, a defined manufacturing process, protected debug policy and a repeatable release pipeline. It also needs an update process that fits the physical product: how technicians connect, what happens if power is interrupted and how the device is recovered in the rare case that both normal operation and the new image fail.
The case study is useful whenever a product needs local field maintenance without permanent Internet access, especially when custom electronics, firmware and the technician-facing interface need to work as one system.
Read the full case study on the Silicon LogiX Solutions Hub.
Top comments (0)