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]

Thanks for your reply, I'll have a look into the various modes later one. 

Just a final question - so there's really no way of updating all three images with the revert posibility? Even if we e.g. do it one by one? I'm mean any way - even something really hacky? 

I'm sorry I'm asking pretty much the same thing from a different angle, but I need to be 100 % sure before I present this to my colleagues. 

Thanks,

Ladivin

[AHaug]

Hi,

No worries about the amount of questions. 

I did some more investigation and I have found the reason for why it is not possible for the netcore. In general we don't support reversion of the netcore image AFAIK, which is because of how DFU of the netcore is implemented. DFU of the netcore is handled through simulated RAM, and not in flash as with other parts of the image. This is a one-way transport, i.e after it is written to the netcore from SRAM, it can't be revertedl

From https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.html it is stated in a note that "The application core does not have direct access to the network core flash memory. The update image is passed indirectly using RAM. Because of this, the mcuboot_primary_1 must be stored in ram_flash region"

Let me know if this answers your question

Kind regards,
Andreas

[Ladivin]

Hi,

again, many thanks for your responses, and your patience :) I understand the limitation regarding the network core image. 

There is one more idea I have - would it be somehow possible to update all three images (app + net + qspi flash) and make app + qspi flash images reversible? Of course, net image would not be reversible, that's clear. 

Thanks,

Ladivin 

[AHaug]

Happy to help

Ladivin said:

There is one more idea I have - would it be somehow possible to update all three images (app + net + qspi flash) and make app + qspi flash images reversible?

Hmm, I will have to look closer into this, but my initial guess is that it might be possible. You might be aware of this, but I'm stating it anyways: One of the reasons for why we recommend simultaneous DFU of both the app and netcore at the same time is so that you don't break the interface (rpmsg / ipc or other) between them. 

Lets consider the case of nonsimultaneous of app and netcore (and put xip part on the sideline): If you do this you will first upload the app core image, reboot the device and swap to the new image. The next step is to upload the image to the netcore and repeat the same steps, but if you in the first step has broken the interface between the cores (for instance that the app core is no longer compatible with the previous interface), you can't use the netcore and BLE to upload the new image to the netcore. Let me know if you're still following or not and I'll clear up my explanation.

But as mentioned, I will look into this and verify if the combination you were asking about and get back to you after the weekend

Kind regards,
Andreas

[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