Updating Legacy Bootloader (SDK 11.0) With latest Secure bootloader (SDK 17.0)

[David]

Hello,

I have a production device (NRF52840)  running a version of the Legacy bootloader from SDK 11.0 and I need to update this to the latest secure bootloader.

Old Device: (SDK 11, S132)

New Device: (SDK 17, S140.7.0.1)

I followed the steps in this link https://devzone.nordicsemi.com/f/nordic-q-a/18199/dfu---updating-from-legacy-sdk-v11-0-0-bootloader-to-secure-sdk-v12-x-0-bootloader which was helpful. This link suggests to create an intermediary bootloader with changes that enable it accept the new bootloader.

There was no support for nRF52840 (pca10056) in SDK11, so I had to port the code for pca10040 to pca10056. I have implemented the changes discussed in the link above. I also changed the bootloader start address to match the start address of the new bootloader ( uicr_buffer[0] = 0x000F8000 ).

Now I am able to upload my intermediary bootloader to the device and it advertises and seems to be working well.

When I perform DFU operation with just final target bootloader, The operation is successful but the device is bricked and does not advertise. I suspect that the final bootloader (based on S140) is not compatible with the S132 Softdevice. There is also a chance that some final steps needed when the device restarts did not complete successfully.

Using my first theory, I try to send a dfu package containing both bootloader and softdevice, but this fails.

Original Bootloader: https://github.com/adafruit/Adafruit_nRF52_Bootloader

New Bootloader is the latest Secure bootloader in SDK 17.0.0.

Can someone point me in the right direction, do I need to make more changes to the intermediate bootloader before it can accept a softdevice update?

[Vidar Berg]

Hello,

I'm afraid it will not possible to do a full upgrade from SDK 11.0.0 in this case. The reason is that the MBR variant distributed with s132 use the 52832's BPROT for flash protection instead of the ACL during the bootloader activation ( ie when bootloader issues the 'SD_MBR_COMMAND_COPY_BL'  command). Support for DFU of the bootloader itself requires that you already have the MBR from s140 v6.0.0 or later already programmed onto your device.

[David]

Hello,

Thank you very much for your prompt reply. How much compatibility is there between newer firmware (e.g latest secure bootloader) and old SoftDevice versions?

My understanding is that the softdevice exposes function calls and it is the implementation of these function calls that change in newer versions. Can the New Secure bootloader work with the old softdevice (S132)?

[Vidar Berg]

Hello,

Your understanding is correct - the APIs change slightly as new features are added to the stack. And the API changes is the reason why you need to combine major Softdevice updates with a new compatible bootloader (SoftDevice and bootloader).

It wouldn't require too many changes to make the secure bootloader work with an older Softdevice. But the limiation as I mentioned earlier is that you will not be able to do DFU of the bootloader itself so you can't update to a different bootloader, which again would be required to allow an OTA upgrade to s140 v7.

I do not see any way you can work around this, unfortunately. The MBR can't be updated through DFU.