nRF5340: SMP Server with external XIP sample with image revert possibility

[Ladivin]

Hi all,

by default, the "nRF5340: SMP Server with external XIP" sample does not support reverting images in case DFU was not successful. In other words, it does not swap slots, it just copies the new image over the old one. This is caused by the config CONFIG_BOOT_UPGRADE_ONLY being set to "y". 

I had no luck building the sample with CONFIG_BOOT_UPGRADE_ONLY=n. I had a look into C:\ncs\v2.6.1\nrf\modules\mcuboot\nrf5340_exip_image.conf and I can see that this config is set to "y" there. Also there is a note stating that this config is needed to make simultaneous multi image update possible. Does this mean that the only way to achieve multi image DFU for nrf5340 with part of code in QSPI flash is to have this config set to y? Or to make the question more generic - is there a way to have the posibility of reverting images after update in this multi image + QSPI XIP scenario? 

Thanks!

[AHaug]

Hi,

Does this mean that the only way to achieve multi image DFU for nrf5340 with part of code in QSPI flash is to have this config set to y

Yes, this is correct

Kind regards,
Andreas

 

[Ladivin]

Hi Andreas,

thank you for the quick answer! I have a follow up question.

I can see that this sample (nRF5340: SMP Server with external XIP) got some updates in the new version of the SDK (2.8.0). If I understand it correctly, if I wanted to update only two images (app + QSPI flash and NOT net core), I can use other modes, right? I can tell because the sysbuild_no_network_core_directxip.conf contains SB_CONFIG_MCUBOOT_MODE_DIRECT_XIP=y. 

In other words, the requirement to have CONFIG_BOOT_UPGRADE_ONLY=y applies only if all of the three images are to be updatable? 

Thanks, 

Ladivin

[Ladivin]

Hi Andreas,

again, many thanks for the explanation. I understand. If you had a chance to verify the combination we were discussing it would be great.

Best Regards,

Ladivin 

[AHaug]

Hi, 

I had discussion with the bootloader devs and the conclusion is that the combination you're asking for is not supported. It cannot be supported because of a dependency of MCUboot which is closer described here: https://github.com/mcu-tools/mcuboot/issues/1950 

Kind regards,
Andreas

[Ladivin]

Hello,

so the final conclusion is that if one wants multi-image update, there's no way revert, correct?

Many thanks for your help!

Best Regards,

Ladivin 

[AHaug]

Ladivin said:

so the final conclusion is that if one wants multi-image update, there's no way revert, correct?

From my understanding, this is not supported for the nRF5340. This might be different for the nRF54L15 (which uses "regular" MCUboot DFU) and nRF54L20 (which uses SUIT).

Kind regards,
Andreas

[Ladivin]

Hi Andreas,

I apologize for revisiting our previous discussion, but I have one more question.

I understand our conclusion about the lack of revert options for the 3-image update on the nRF5340, and I won't dispute it.

I want to confirm something: since SDK version 2.8.0, the "nRF5340: SMP Server with external XIP" sample allows for "direct XIP" mode, which does enable revert options. In the configuration (like "sysbuild_no_network_core_directxip.conf"), the network core is empty. This indicates that a network core update isn't possible, but does it also mean the network core must be empty?

I'm asking, because I would like to know if it's possible to update only 2 images (the application and external flash) via BLE and still have the revert option. 

Thank you very much in advance. This is a bit difficult to explain, so if more details are needed, just let me know

Best,

Ladivin 

[AHaug]

Hi again Ladivin,

No worries, always good to discuss complex questions a bit closer to understand them better.

That's a good question. SB_CONFIG_NETCORE_NONE=y sets the netcore empty, as you say, meaning that you don't have anything on the network core. But if you want to an update of only 2 images (app and external flash) via BLE this indicates that you have something on the netcore i.e the hci_ipc companion component (previously known as child image), meaning that you conflict with SB_CONFIG_NETCORE_NONE=y.

My understanding of this config is that it's only for non-BLE configurations of the nRF5340, meaning that you won't be able to perform FOTA over BLE since the network core is empty. It might be useful if you have a multi-MCU board where another BLE compatible device receives the XIP_no_netcore__directxip image, sends it over serial to the nRF5340 which has an empty netcore over serial and then MCUboot on the 5340_no_netcore performs the update using that image.

Kind regards,
Andreas

[Ladivin]

Hi Andreas,

Again, many thanks for your response.

So if I understand it correctly, the SB_CONFIG_NETCORE_NONE=y is mandatory in this case? In other words, the only way to enable the revert option in a multi-image scenario for single nrf5340 is to update just two images (app + external) while also having an empty network core (meaning no BLE) at the same time?

Best regards,

Ladivin

[AHaug]

Ladivin said:

So if I understand it correctly, the SB_CONFIG_NETCORE_NONE=y is mandatory in this case?

Correct

Ladivin said:

In other words, the only way to enable the revert option in a multi-image scenario for single nrf5340 is to update just two images (app + external) while also having an empty network core (meaning no BLE) at the same time?

Yes, this resonates with my understanding of how direct-xip at least, and you will have to add the revert mechanism on top of the no_netcore_direct_xip configuration (explained here: https://docs.nordicsemi.com/bundle/ncs-latest/page/mcuboot/design.html).

Do also pay attention to the drawback mentioned there" Handling the primary and secondary slots as equals has its drawbacks. Since the images are not moved between the slots, the on-the-fly image encryption/decryption can’t be supported (it only applies to storing the image in an external flash on the device, the transport of encrypted image data is still feasible)." in case encryption and decryption is a concern for you.

Do note I'm fairly confident my understanding is correct, but I've not tested and developed anything with this specific configuration. I've only discussed it with my colleagues, read the documentation and investigated the samples you've also been working with 

Kind regards,
Andreas