Migrating nRF52840 Firmware from nRF5 SDK with SoftDevice S140 to nRF Connect SDK via BLE DFU

[Zadock Maloba]

We currently have several nRF52840-based devices deployed in the field, running firmware developed using the nRF5 SDK and utilizing the SoftDevice S140 for BLE functionality. These devices are equipped with the nRF Secure Bootloader to facilitate Device Firmware Updates (DFU) over BLE.

As we plan to transition our firmware development to the nRF Connect SDK (NCS), we aim to update our existing devices to the new NCS-based firmware via BLE DFU. Given the differences between the nRF5 SDK and NCS—particularly concerning bootloaders and BLE stack implementations—we seek guidance on the following:

1. Can the existing nRF Secure Bootloader be used to directly update the application firmware to an NCS-based version? If so, what modifications are necessary to ensure compatibility?
2. Is it advisable to perform a two-stage DFU process, first updating the bootloader to MCUboot and subsequently updating the application firmware? What are the recommended steps to achieve this without physical access to the devices?
3. Considering that the nRF5 SDK relies on the SoftDevice S140, while NCS utilizes the Zephyr BLE stack, what considerations should be made to ensure a seamless transition during the DFU process?
4. What are the best practices for managing memory layout changes when migrating from nRF5 SDK to NCS, especially in the context of DFU?

[Hung Bui]

Hi Zadock, 

It's possible to do DFU update from nRF5 to NCS SDK. But we don't have an official support for DFU update from NRF5 SDK to NCS. What we have is some workaround solution provided as-is, that techsupport made to help customer doing the task.

You can find the solution in the following discussion: 
RE: Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application 

And some more updated info in this discussion:  Update from nRF5 SDK to nRF Connect SDK 

I would suggest to study the 2 above links. Note that after the DFU update, the NCS application will have to be configured to cope with the fact that the MBR is still in the flash and the MCUBoot location is relocated to the top of the flash area. 

[Bruno Randolf]

Hi! I just solved this by following what is explained in that blog post: https://www.embeddedrelated.com/showarticle/1573.php. I use it on nRF52833 with external SPI flash. It works really well and the benefit to the other methods discussed here is that you end up with the exactly same flash layout as if using NCS from scratch (no MBR).

Basically you create a GATT characteristic which can receive the NCS firmware in binary format and write it to your external flash.

Then you need to modify the bootloader to not protect the flash (remove all nrf_bootloader_flash_protect() calls, also the ones found in the SDK, not only the bootloader project).

And then you need to write some code which runs in RAM only, which erases all internal flash, and then reads from the external flash and writes to the internal. It's less hard than it sounds - an example is given in that link above and even reading from SPI flash is not so hard to do by accessing the NRF peripheral registers directly. Note that you can do all the setup with the usual functions, just reading and writing has to run in RAM only, once the internal flash is erased.

Then you can do a normal DFU of this new APP+SD+BL to your device and then use your new GATT service to transfer the NCS fw image and trigger the update. It was easier than expected! :-)

[Hung Bui]

Hi Bruno, 
Thanks for the link. I think it's can be a good solution with the benefit of being able to completely wipeout the flash and have the normal NCS application flash layout. 
But one drawback of this solution is to have no option for fail-safe or recovery if there is something wrong happen. If a crash or a reset occurs during the time where the code running in RAM is erasing the flash or copying the flash there would be no way to recover.