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!

[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