Upgrade path from nRF5 SDK to nRF Connect SDK after production

[Ryjan]

After a conversation with a Nordic engineer and some research it looks like there is no official way to upgrade a product over the air from an nRF5 SDK based product to an nRF Connect SDK based product. At my company part of the plan with using the nRF52 was to move to Bluetooth Mesh. With nRF5 SDK development ending at the end of this year, new developments for mesh will not added to that SDK so we are adding this to the list of considerations that we are looking at to perhaps jump to the nRF Connect SDK ecosystem.

I wanted to post here and check if there was anything coming down the pipeline to jump from nRF5 SDK to nRF Connect and or open discussion on how this can be done.

So far my plan for an in-field upgrade is to make a bootloader and softdevice package that can be loaded into application space and will verify its validity before switching the device to run on this new new bootloader in it's new location. This bootloader would be modified to accept the MCU bootloader and a light weight application with the components needed to run the bootloader in the proper locations in memory. Once verified the MCU bootloader will be targeted to run after reset and then a proper application can be uploaded. I have quite a bit still to learn about the MCU bootloader and it's dependncies on the Zephyr system.

Any comments, ideas or a pointer to others else who are working on this issue are welcome.

[Edvin]

Hello,

We don't discuss roadmap details on DevZone, and for that reason, I don't know whether your claims regarding ending development for the nRF5 SDK are correct or not. 

If you want to discuss this, please contact the RSM for your area. Send me a PM here on DevZone where you verify your location, and I can send you some contact details.

Regarding upgrading from the nRF5 SDK to nRF Connect SDK via a DFU:

There is no trivial way to do this, and from our side, we do not support this. 

You already touched into some of the reasons why it is not trivial, but I can try to give some more information.

When the nRF is powered, it starts the application at 0x00000000, and runs into the MBR (part of the softdevice or standalone MBR). It is then asked to check the register containing the bootloader address. If this is 0xFFFFFFFF, then it will continue, and it will start inside the softdevice if present. If not present, that address will be the start of the application. If the softdevice is present, then the softdevice will forward it to the application start address.

Now, if you want to change the bootloader start address, you need to configure the UICR (in the best case, but it may also be located in the MBR). Deleting the UICR during runtime is possible with the nRF52832, but not the rest of the nRF52 series. 

So if you are doing this on an nRF52, there is still a chance it may work, but not certain. I don't think it is done before. To be honest, I am not sure what the same procedure is of the bootloader in Zephyr yet, but you would have to erase the MBR and softdevice, and update to the new BLE stack. If something goes wrong during this procedure, the device is bricked.

So I would say that it is not possible to update from nRF5 SDK to the NCS via DFU, unfortunately. 

BR,

Edvin

[Ryjan]

You said that the UICR can be re-written during runtime only on the nRF52832. I'll ask the seemingly obvious question of does that mean the nRF52840 does not have the same capability? We are still digging into this deeper to get a full understanding.

We thought it would be possible mostly because of this question in this webinar on the nRF Connect SDK: https://www.youtube.com/watch?v=Cj1Fy4ePBgQ&feature=youtu.be&t=4945. I understand plans change, but I also understand that something could be missed easily.

[Edvin]

Ryjan said:

I'll ask the seemingly obvious question of does that mean the nRF52840 does not have the same capability?

 That is an important question, but yes. It means that you can't do that on the nRF52840. The UICR are read only during runtime on this chip.

I asked the person who answered the question in the webinar, and he said that this was something we considered, but it was decided that this is not something we will make, because it doesn't seem like a good solution. One thing is that you can't erase the MBR, but the bootloader requires a softdevice (if you intend to use a BLE bootloader), which you will not be able to skip. Since you can't change the MBR or UICR, you can't update to an NCS bootloader. One alternative is to use the USB bootloader, but that may not work in your case. This is what we landed on for the nRF52 dongle. 

That being said. It is not impossible to create an nRF5 SDK -> NCS Bootloader transition over BLE, but it is not something that we will provide, I am afraid.

Best regards,

Edvin

[Ryjan]

To clarify another thing that was brought up, the MBR cannot be changed because the NCS bootloader or the nRF5 bootloader protect those areas or is there some other protection that I am not aware of?

Concerning writing to the UICR at runtime: I reviewed the product specification for the nRF52832 and the nRF52840 and the registers to manipulate the UICR registers seem identical. If I can write to a UICR register in the nRF52832 it looks like I have the same ability in the nRF52840. Can you help me understand the difference?

[Edvin]

Hello,

Actually, it looks like the UICR is not writable on the nRF52840 only if APPROTECT is enabled. NB: If you want to experiment with this, please insert a delay in your application before trying to erase the UICR when APPROTECT is enabled, so it is easier to recover it after APPROTECT is enabled.

NB: To disable APPROTECT, you need to modify the UICR, so if you have enabled APPROTECT at some point, you need to erase the entire flash in order to turn it off (because APPROTECT is enabled in UICR).

You can't change the MBR because it is the MBR that does the shuffling when the bootloader wants to replace itself.