Migrating from nRF5 SDK to Nordic Connect SDK via BLE DFU (nRF52840)

[Rokk Research]

Hi there, we have many nRF52840 devices in the field that currently run firmware based on the nRF5 SDK. We'd like to port our codebase to the nRF Connect SDK for all new products, and would like to update existing devices via BLE DFU, so that we don't have to maintain 2 separate codebases moving forward.

I've seen several (older) threads on this topic, but it's not entirely clear to me if this is supported, or if it's even possible, as there is some conflicting information. From what I understand, it'd have to work something like this:

• patch and DFU the existing nRF5 SDK bootloader, so that it will continue booting an application even if it can't find the SoftDevice magic
• build the NCS based app with MCUBoot enabled, and put MCUBoot at an address where it doesn't interfere with the MBR or nRF5 SDK bootloader
• DFU the merged MCUBoot + NCS application, overwriting the SoftDevice
• the nRF5 SDK bootloader will boot, skip the SoftDevice signature check (because we patched it in step 1), then continue booting into MCUBoot
• future DFU's will be performed using MCUBoot

Does that sound about right? Has anyone been successful doing this with a recent release of the Nordic Connect SDK? It seems to me like this would be a relatively common request, as devices in the field running firmware based on the nRF5 SDK would eventually want to migrate over to firmware based on the Nordic Connect SDK.

[Edvin]

Hello,

Unfortunately we do not support DFU from the nRF5 SDK to NCS from Nordic's side. 

I know that some have tried to do this, and some may even succeeded, but it is not trivial, and the benefits from this is not that large, as I see it. 

I recommend that you only use NCS for new products, but upgrading a product in field from nRF5 to NCS, I can't really see the use for. Are there any new features that you want to add that are only present in NCS?

All this being said, perhaps there are anyone else here who have successfully managed to DFU from nRF5 to NCS and would like to share?

Best regards,

Edvin

[Rokk Research]

Hi Edvin,

Thanks for the reply, it's helpful to know Nordic's official position regarding support for this functionality. Regarding why upgrading a product in field from nRF5 to NCS is important, there are several reasons in our case, which include:

• The current NCS codebase needs to be rewritten, as it is buggy and unmaintainable. If we're going to spend the effort to rewrite it, using NCS is preferable, as the nRF5 SDK is no longer being developed

• The current codebase contains older, unmaintained versions of various sensor drivers, which were not present in the nRF5 SDK. These drivers are now included as part of NCS, so moving the current codebase to NCS would eliminate the need to maintain the sensor drivers ourselves

• There may be new features in NCS that aren't available in nRF5 that we plan to use

• Probably most importantly, all new product development will be based on NCS. Therefore, the desire is not to have to maintain 2 separate codebases - 1 for nRF5, and 1 for NCS. For example, adding a new feature would require adding it to 2 separate codebases (one based on NCS, and one based on nRF5) which would essentially double the development effort

In our case, it would be much more desirable to first migrate the devices in the field to NCS, and use that same codebase for both existing devices in the field, as well as new product development.

I hope that makes sense, and I would love to hear from other folks who have attempted this, whether successfully or not.  Thanks!