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!

[Bruno Randolf]

Hi! I would also like to add some arguments or viewpoints why upgrading from SDK to NCS might be useful for someone using Nordic devices. The company I work for maintains ~10.000 Nordic devices in production environments, and obviously it would be impossible to replace all this hardware, just because of a new SDK.

The firmware development doesn't say still. It's not like we pushed out this product with firmware version X and it will stay like that for the lifetime of the product. We are constantly improving the firmware and upgrading the devices, so far with good success.

For example, just now, a new HW model with specific features should be integrated into the existing firmware, and this brings a lot of library dependencies, some of which are already available for Zephyr/NCS. I could of course add all that to the existing FW based on the old SDK, but it would be a lot of effort to implement things which would already be available or easier to do with NCS. That could be okay in general, but not if this is a dead end street.

It would be more useful, much faster and future-proof to start supporting this HW feature with a new firmware based on NCS, which comes with the new devices only, but then I would have to maintain two different versions of the firmware with the old and the new SDK, probably for years to come!

Both options are not good.

According to the comments I read here, technically it seems to be possible to upgrade from SDK to NCS, allthough not ideal, because there it would have to be a multi-step upgrade and it would not be as efficient as a native mcuboot/NCS app due to the MBR. But I guess, giving it enough attention it would be possible to solve and upgrade reliably.

So I would like to ask Nordic to reconsider the possibility of providing a smooth(er) upgrade path between the old and the new SDK because in practice it's not so easy to say "just use the NCS for new products". Thank you

[Edvin]

Hello,

Thank you for your feedback. I will forward it to our product management.

Don't shoot the messenger here, but I believe the decision is based on the fact that devices in field don't typically get game changing FW updates. The nRF5 SDK is in maintanance mode, meaning no new features will come there, but adding e.g. audio over BLE to a product already on the market is not something that is likely to happen, becuase it will also require the product to have additional HW.

So the claim here is that if you have a product, unless you tend to do groundbreaking changes, you can keep that entire series on the nRF5 SDK for the remaining lifetime of the product. 

However, I do understand what you are saying, and I agree that the best thing would be that there was an easy tutorial on how to DFU from the nRF5 SDK to NCS. However, because there will be so many flavours and different setups, this guide will cost a lot of work, and maintanance. 

That being said, it is not impossible. But as we see it, the cost (use of time) of implementing this for all cases thinkable for our users is too big, and it will slow down other features that are needed in our perspective.

But I will forward your arguments to our decision-makers. 

BR,

Edvin

[Bruno Randolf]

Thank you for considering it.

One idea I had in the mean time: would it be feasible or easier, to keep the current bootloader, but load the ncs application from there?