MCUMGR compatibility with new SDK versions

[Utsav R Shah]

Hello community,

I am working on a custom nrf5340 board design, that uses the BL5340PA external antenna module to implement the nrf5340 chip in the design. The BL5340 module allows all of the base functionality in the nrf5340 module, but also adds an external FEM in increase the TX power. 

I am utilizing the Zephyr/nrf SDK version 2.4.1 (received from Laird for updated TX power setting rules: GitHub - LairdCP/bl5340pa_manifest: Manifest for the Laird Connectivity fork of the nRF Connect SDK with support for the BL5340PA).

This forked version of the 2.4.1 SDK contains the BL5340PA board support packages and so far my application is running fine using this SDK version. 

I just wanted to check if the mcuboot version which is being utilised in this SDK version would be compatible with later releases(2.7.x) of the SDK as well. There are some issues in the current SDK version in terms of SPI communication with the FEM module that is supposed to be fixed in upcoming SDK versions. My project also utilises the DFU mechanism using Serial Recovery. I just wanted an input from the nordic community on the instance that I may in future develop application for the BL5340 PA board on the new SDK version and update the same via DFU mechanism while the board would still run an older version of mcuboot bootloader. Could this create any compatibility issues in the future, for which I would have to update the mcuboot of the board as well or the newer SDK's would have backwards compatibility? 

Any inputs for this would be great!

[Sigurd Hellesvik]

Hi,

So your question can be summarized as:

"Can I use an earlier version of MCUboot with serial recovery to OTA to a new NCS app?"

Correct?

Regards,
Sigurd Hellesvik

[Devin M]

 Sigurd Hellesvik Hi, I am working with Utsav on this as well. Our BL5340PA module has the current capability of updating the app core and net core using the Serial Recovery method. You are correct, we just want to ensure that if we update the net and app core images to a higher version of SDK (2.4 to 2.7 or higher for future), that the Serial Recovery bootloader would still be functional with a different SDK version running in the app core and net core. 

So overall MCUBOOTloader would be from 2.4. SDK and the app core and net core would be from 2.7 or higher SDK. 

Or is there a method to update the bootloader as well using Direct Serial Recovery, along with the app core and net core so we would not have to worry about this.

For some context we will be switching to 2.7 SDK due to a bug fix in that SDK from Nordic's SoftDevice, and wondering if we can move forward with our temporary fix in 2.4 SDK and update to this functionality later in 2.7 SDK 

Thanks,

Devin

[Sigurd Hellesvik]

On the app core, do you run one or two bootloaders?

(I got a detailed answer for you, just want all the context first, so I can answer as precisely as possible)

[Devin M]

From my understanding, it is one bootloader that is separate from the app core and net core. As using direct serial recovery, the bootloader directly writes over byte-for-byte the app core and net core when doing an update. 

If I am misunderstanding I can send you any necessary configurations from our project to help clear this up. I know net_core uses b0n bootloader within its image. And below is the configs from prj.conf to configure the bootloader:

##Enable the MCUBoot Bootloader

CONFIG_BOOTLOADER_MCUBOOT=y

#enable the netcore binary file generation

CONFIG_NRF53_UPGRADE_NETWORK_CORE=y

CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y

The rest are in the hci_rpmsg.conf

[Sigurd Hellesvik]

Alright, let's take it from  the top:

Will an old version of MCUboot DFU newer apps?
Answer: Yes

Caveat: You must make sure that you have the same partitioning between all apps. See Static partition requirement for DFU.
Caveat: You must use the same key to sign both versions of your firmware.

Nice thing about Serial Recovery is that if the DFU does not work, you can always just enter DFU mode again and retry.

Explanation:
The Bootloader has a simple job: To put firmware in the correct place, and then to boot that firmware if it can verify the signature of said firmware.
The bootloader does not care otherwise about the firmware. So you can even DFU apps compiled with something else if you would somehow want that. (But you would not want that)

Answers to your questions:

Could this create any compatibility issues in the future, for which I would have to update the mcuboot of the board as well or the newer SDK's would have backwards compatibility? 

No. Especially not when you have Serial Recovery.

Devin M said:

Or is there a method to update the bootloader as well using Direct Serial Recovery

No, bootloader can never be updated over DFU. Only overwritten by a debugger. This is a security feature.

Does this answer the ticket?

[Devin M]

That seems to answer it well for me, thank you for that detailed explanation. Makes sense to me and was my initial thought on the functionality but wanted to verify so we don't get stuck down the line. 

Thanks for your help! I will let Utsav set that as the answer

[Utsav R Shah]

That works for us! Thank you Sigurd Hellesvik  for you inputs on this.