nRF52811 OTA/DFU Feasibility

[Purvesh patel]

Background

I'm working on a BLE application for the nRF52811 and facing significant flash memory constraints when trying to implement OTA/DFU functionality.

From my understanding and research on DevZone, it would be difficult to do OTA with BLE on nRF52811 with nRF Connect SDK as it does not support single slot DFU over ble and due to insufficient flash space for dual slot. This has been confirmed in multiple threads:

• Single-slot DFU using MCUboot
• nRF52811 Zephyr with MCUboot
• nCS and MCUboot DFU over BLE not enough image space

As such, I'm planning to migrate to the legacy nRF5 SDK to test the feasibility of implementing OTA on nRF52811.

Current Flash Usage Analysis

• Simple BLE blinky (nRF5 SDK): 122 kB of 192 kB (63.6%)
• Buttonless DFU without bootloader (nRF5 SDK): 152 kB of 192 kB (79.1%) [without bootloader]
• Basic Ble application (nRF Connect SDK): 128.76 kB without activating mcuboot

Questions

1) Will OTA work with nRF5 SDK on nRF52811? Given the flash constraints, is it technically feasible to implement a complete OTA solution (including bootloader) within the 192 kB flash limit using nRF5 SDK?

2) If yes, will it be single slot DFU? What type of DFU mechanism would be used? Single slot or dual slot? How would the flash partitioning work?

3) Single slot DFU reliability - Recovery mechanism If it will be single slot DFU, what happens if there's an error during firmware transfer (power loss, connection drop, corrupted data)? Can the device be recovered thereafter using OTA, or would it require physical access/JTAG programming?

4) nRF52811 product lifecycle How long will Nordic continue to sell the nRF52811? A rough estimate would suffice for planning purposes. Are there any end-of-life announcements or roadmaps available?

5) Power optimization comparison - nRF5 SDK vs nRF Connect SDK Will I be able to achieve the same level of power optimization with nRF5 SDK as with nRF Connect SDK, especially in the absence of Zephyr's power management features? Are there specific power management APIs/features in nRF5 SDK that can match nRF Connect SDK's efficiency?

6) OTA transfer speeds and power consumption I understand from this discussion that nRF5 SDK has slower OTA speeds compared to nRF Connect SDK. What would be the typical transfer rates, and how significant is the power consumption impact during OTA operations?

7) Bootloader size overhead What would be the typical flash overhead for the nRF5 SDK bootloader? How much application flash space would remain available after accounting for the bootloader?

8) Migration complexity Are there any major architectural differences or gotchas when migrating from nRF Connect SDK back to nRF5 SDK that I should be aware of, particularly for BLE applications?

9) Alternative solutions If nRF5 SDK also proves insufficient for OTA on nRF52811, what would be Nordic's recommended migration path? 

Additional Context

• Target application: Low-power BLE device with periodic OTA updates
• Flash usage optimization is critical
• External flash is not an option due to cost and space constraints

Any insights, experiences, or guidance would be greatly appreciated!

[Vidar Berg]

Hello,

Yes, OTA dfu is supported on the nrf52811 as long as the application is not too big. But if you have already developed the application with the nRF Connect SDK but not the hardware, it should be easy to transition to the nRF54L series devices, which offer more memory and performance at a lower cost.

Simple BLE blinky (nRF5 SDK): 122 kB of 192 kB (63.6%)

This is including the Softdevice which won't be upgradeable  with this setup. To get the size of the app you must substract 122 with the size of the softdevice you've selected.

[Purvesh patel]

Hello Vidar,



text:

// <q> NRF_DFU_SINGLE_BANK_APP_UPDATES  - Place the application and the SoftDevice directly where they are supposed to be.
 

// <i> Note that this creates security concerns when signing and  version checks
// <i> are enabled. An attacker will be able to delete (but not replace)
// <i> the current app or SoftDevice without knowing the signature key.

#ifndef NRF_DFU_SINGLE_BANK_APP_UPDATES
#define NRF_DFU_SINGLE_BANK_APP_UPDATES 1
#endif

Testing Results [currently testing for nrf52840 on nrf52840 dk with old nrf5sdk]

Wrongly signed file test:

• Transfer immediately stopped with log: [DFU] Remote DFU error: invalid object
• Upon reset/timeout, device behaves normally
•  Invalid Object error with OTA DFU using both example and self generated packages. points it is due to key 

Questions

1. Security concern confirmation: Can you confirm the actual security risk? Based on my testing, wrongly signed files are rejected immediately - I cannot successfully perform the attack described in the warning.

Also

Purvesh patel said:

3) Single slot DFU reliability - Recovery mechanism If it will be single slot DFU, what happens if there's an error during firmware transfer (power loss, connection drop, corrupted data)? Can the device be recovered thereafter using OTA, or would it require physical access/JTAG programming?

I tried disconnecting my Bluetooth connection midway during the DFU process, and I observed that the device gets stuck in DFU mode, advertising as DFUTARG. It can only be recovered by performing a successful OTA update.

However, I am wondering about other possibilities — for example, what happens if the firmware data itself gets corrupted during transfer?


Can you confirm me this two things?

Testing for nr52811 on nr52840 dk

I got the same error as this 

 peer_manager_pds: Could not initialize flash storage. fds_init() returned 0x860A 

but i can't access many links given in the solution 

[Vidar Berg]

They can initiate the DFU process by reusing the init command from a valid update (an init command signed with your key). They will not be able to update to another firmware, but they can use this to erase the current application.

Purvesh patel said:

However, I am wondering about other possibilities — for example, what happens if the firmware data itself gets corrupted during transfer?

The integrity of the received FW is validated against the hash in the init command. The bootloader will fall back to dfu mode if the validation fails.