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

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

Vidar Berg — Tue, 08 Sep 2020 09:15:32 GMT

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.

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

David — Mon, 07 Sep 2020 14:12:46 GMT

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)?

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

Vidar Berg — Mon, 07 Sep 2020 12:58:24 GMT

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.