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?

[Edvin]

Bruno Randolf said:

would it be feasible or easier, to keep the current bootloader, but load the ncs application from there?

Let me consider what that would imply.

If you want to keep the current bootloader, and this is a BLE bootloader, then that would require you to keep the softdevice in the flash, which is less than ideal. Especially on the nRF52832, which this DevZone Ticket originally asked for. There is not a lot of flash left for the NCS application then (which will not be able to utilize the nRF5 Softdevice).

Other than that, if you keep 2x Bluetooth stacks, that would be possible.

The main issue (in this original ticket) is the flash space present on the nRF52832. The NCS applications and stacks in general takes up more space than the nRF5 SDK variants. One other option would be to strip out the bluetooth from the nRF5 SDK bootloader, and use this as a "background bootloader", meaning the application will handle the transfer (which could then be tailored to match the mcumgr image, but with the exception that something would have to be tailored with how the image is created and signed, either in the bootloader or in the image from NCS). In that case, you would also need to disable a check that the bootloader does which checks whether a softdevice is present or not. It is a rather simple fix, but it requires another step. 

I think the main issue with this (DFU from nRF5 to NCS) is that depending on your initial conditions, this DFU can have very many different requirements, which makes it very hard to support from an Nordic's official point of view. That does not mean that it is not possible. Just look at the nRF52(840) dongle, which is able to use the preprogrammed nRF5 bootloader to receive NCS applications. This is a USB bootloader, though, which simplifies things a bit, and the bootloader is fairly small. 

I don't know exactly how it is done, but I imagine it is quite close to your suggestion.

If you want to replace the nRF5 bootloader completely, you need to have something in the old bootloader's place that forwards the vector table from the old bootloader address down to your new bootloader, meaning the flash area around your old bootloader is more or less useless from that point. Then you need to keep the MBR starting at 0x00, because there is no way for it to delete itself. So you would need to shift everything 0x1000 up (past the MBR) in the flash. 

So if this is something you really want to consider, you can check the forum (DevZone) for similar cases, and it is doable, but it requires some extensive knowledge on how both the old and the new bootloaders work. And at this point in time, it is not something that we can give extensive support on. Trust me, if I already knew how to do this straight forward, I would've told you/the user who created this ticket a long time ago.

Best regards,

Edvin