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]

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

[Rokk Research]

Hi Edvin and Bruno Randolf, FYI I was able to figure out how to FOTA nRF5 based firmware to nRF Connect SDK firmware on the nRF52 for our devices in the field - please read on if you're interested in how I did it.

The nRF5 SDK bootloader uses Access Control List (ACL) to set the MBR region (the first 0x1000 bytes of flash) and the bootloader region (toward the end of flash) to read-only. I modified the bootloader to remove this protection, so that the MBR and bootloader can be overwritten, and pushed out a bootloader FOTA update.

Next I added a BLE service to the application, that accepts the NCS-based merged firmware binary image (combined MCU bootloader plus application), and writes it to a region in an external SPI flash.

Finally, I added some upgrade code that runs entirely in RAM, and erases the nRF52 flash, and copies the binary image from SPI flash into the nRF52 flash, starting at address 0. This code has to run in entirely RAM because otherwise it would overwrite itself, and it has to run with interrupts disabled because it's erasing the exception vectors.

The tricky part about running entirely in RAM is that you need to write new versions for things like setting LEDs (I toggle an LED during flash erase and image copy), the SPI driver to read external flash, calculating CRC's, etc because it cannot make any calls to any functions on internal flash. One trick I took advantage of is XIP support on the nRF52, so reading from external SPI flash is just a memory-mapped IO read.

There were a couple of other tricks unique to our codebase, but that's basically it - we now have an upgrade path to FOTA all of our nRF5 SDK based devices in the field to nRF Connect SDK based firmware, without having to RMA them to re-flash via SWD!

Here's a post I wrote up on the approach:
nRF5 to nRF Connect SDK migration