Over-the-Air firmware upgrade protocol, which includes the standard nRF52 DFU and the custom UART-SPI protocol, for upgrading several MCU / SoC using a single ZIP archive. For example: upgrading nRF52 and ESP modules of Fieldbus Anchor or upgrading nRF52 and STM32 modules of Locator Pro.
The transfer is wireless and no chip erase is involved. The nRF52 stage is the same on every device; what differs is which second processor it carries and over which link it reaches it:
| Device | Processors upgraded | Inter-processor link |
|---|---|---|
| Fieldbus Anchor, Locator Lite | nRF52 + ESP | UART |
| Locator Pro | nRF52 + STM32 | SPI |
| Locator Lite XT | nRF52 | — |
The rest of this page describes the nRF52 stage, which is common to all of them, and then the ESP stage in detail.
These devices carry two processors, but the update package contains one image. The second processor's firmware is compiled into the nRF52 application as a byte array, so shipping the nRF52 application ships both. The diagram below shows the ESP case; Locator Pro works the same way with an STM32 image and an SPI link:
This is why the application is large — roughly 432 KB, most of the difference being the embedded image — and it is what makes the second stage need no operator action.
The device runs Buttonless Secure DFU:
Send the package with nRF Connect for Mobile — connect to the device, open DFU, pick the .zip — or with nRF Device Manager.
The application version must increase with every release. The bootloader rejects an image whose version is not newer than the one installed, so a package cannot be replayed to downgrade a deployed device.
The application plus a second copy of it would not fit in flash, so the bootloader erases the old application and writes the new one in place. That has one operational consequence worth knowing:
An interrupted transfer leaves the device in DFU mode. There is no old image to fall back to. This is not a failure state — reconnect and send the same package again. The device waits in the bootloader indefinitely and cannot be bricked by a dropped connection.
The application's configuration page sits at 0xF7000, inside the app-data area the bootloader never erases during DFU. A field update therefore keeps the LocatorID, WiFi credentials, server address, radio settings and everything else already commissioned.
| Region | Address range | Size |
|---|---|---|
| MBR | 0x00000–0x01000 | 4 KB |
| SoftDevice S140 7.2.0 | 0x01000–0x27000 | 152 KB |
| Application | 0x27000–0xF7000 | 832 KB |
| App-data area — DFU-preserved | 0xF7000–0xF8000 | 4 KB |
| Bootloader | 0xF8000–0xFE000 | 24 KB |
| MBR parameters | 0xFE000–0xFF000 | 4 KB |
| Bootloader settings | 0xFF000–0x100000 | 4 KB |
The SoftDevice and bootloader are not field-updatable by this path — a single-bank layout leaves too little free flash for a combined package. Changing either is a wired operation with a J-Link factory image.
Nothing is sent for this stage. On every boot the nRF52 asks the WiFi module which version it is running and compares the answer with the version embedded in its own image:
No answer is treated as a mismatch, deliberately. A module that does not reply is usually running firmware too old to understand the version request, or is stuck in a bad boot strap. Reflashing ends with a clean reset and correct strapping, so it recovers exactly the cases a version comparison alone cannot diagnose. The attempt is self-bounded: the flasher gives up after five tries and the device carries on booting rather than looping.
| Step | Detail |
|---|---|
| Warning window | 5 s, red LED blinking rapidly |
| UART released | the application driver detaches so the flasher can drive the pins |
| Reflash | ~45 s, one blocking call, watchdog fed either side |
| Result | green LED pulse on success, red on failure |
| Module reboot | 1 s, then the application re-acquires the UART |
| Settings re-sent | LocatorID, WiFi SSID and password, server address, NTP server, topic prefix |
The final step matters: a freshly flashed module comes up blank, so the nRF52 pushes the commissioned settings back into it. Nothing needs to be re-entered by hand.
To be flashed, the module must be strapped into download mode by pulling one of its GPIO lines low across a reset. On boards where that line is wired to the nRF52 this is automatic and the 5-second window can be ignored.
On PCB revisions where the line is not wired to the nRF52, the module cannot be strapped in software. Hold the S2 (FLASH KEY) button during the blinking window — that is what the window and the blink are for.
The nRF52 speaks the module's ROM serial protocol directly — SLIP framing over UART at 115200 baud, using the standard SYNC, FLASH_BEGIN, FLASH_DATA and FLASH_END commands, in 2 KB blocks written from offset 0x00000.
Entering the bootloader is retried up to five times. A single reset can land on a bad boot — a strap latch that did not settle, or a missed autobaud window — and historically needed a manual power cycle; looping the reset, autobaud wait and sync lets a bad boot recover on its own.
The running WiFi module version is readable over BLE at characteristic 0x8208 (UTF-8, up to 20 bytes) — see BLE GATT. It reports the literal string FLASHING while a reflash is in progress, so a client that connects mid-upgrade sees the actual state rather than a stale version.
0x8208 reads | Meaning |
|---|---|
| a version string | the module is running that version |
FLASHING | a reflash is running now |
| empty | the version check has not completed yet |
The LEDs give the same information without a phone: rapid red blinking is the warning window, a green pulse is success, a red pulse is failure.
| Stage | What happens | Duration |
|---|---|---|
| 1 | Send the .zip from nRF Connect over BLE | depends on link quality |
| 2 | Bootloader verifies the signature and writes the application | seconds |
| 3 | Device reboots into the new application | — |
| 4 | Version check against the WiFi module | a few seconds |
| 5 | Reflash, if the versions differ | 5 s window + ~45 s |
| 6 | Settings re-sent, normal operation resumes | — |
Steps 3 to 6 need no operator involvement. From the phone's point of view the job finished at step 2 — but a device that reflashes its WiFi module is unreachable on the network for roughly a further minute, which is worth allowing for when upgrading a site.