Netcore OTA Update with Direct XIP mode

[Roedy]

I have an nrf5340 device with the following requirements.

• must switch application slots if image becomes corrupt
• can only do OTA updates
• must have the ability to upgrade the network core

In order to enable switching slots, we chose to use Direct XIP mode.  This has thrown the unwanted side effect getting caught in a boot loop when updating the network core. 

To reproduce,

• bump up CONFIG_MCUBOOT_IMAGE_VERSION and rebuild the project
• use mcumgr to send net_core_app_update.bin 
• reset the board

The system ends up getting stuck in a boot loop, which sorta makes sense now that I know how direct XIP mode works.

*** Booting Zephyr OS build v3.3.99-ncs1 ***
I: Starting Direct-XIP bootloader
I: Primary   slot: version=0.0.0+0
I: Secondary slot: version=0.0.1+0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x80000
*** Booting Zephyr OS build v3.3.99-ncs1 ***
... etc etc 

I guess the question is it even possible to update the netcore OTA in Direct XIP mode?

[Amanda Hsieh]

Hi, 

To confirm our understanding, do you have nrf53 with multi-image updates or just a single slot where they update either the application or network core?

Regards,
Amanda H.

[Roedy]

I am doing a multi image build, but I haven't configured multi image updates.  My build currently produces

• MCUboot direct XIP mode
• hci_rpmsg for network core
• app_update (slot 0)
• mcuboot_secondary_app_update (slot 1)

I was able to update the network core without direct XIP, but I'm just not sure what I need to do to update the network core with direct XIP enabled.  

What are the steps to accomplish that?

[Amanda Hsieh]

Hi, 

MCUboot currently can not work in DirectXIP and swap mode at the same time, it is compiled to have only one mode, and making MCUboot support multiple modes at once is not possible without significant effort which is out of our loading now. 

DirectXIP means that app is built to be executed directly from the slot it is placed in, but uploading an update to NetCore requires the image to be passed via inter-process communication means, which in our case is done by the SWAP mechanism pretending to write the app image to the primary slot while actually uploading it to netcore.

The only way to support DirectXIP and Netcore is to have MCUboot do the directXIP but make the application responsible for updating NetCORE after being boot.

-Amanda H.

[Roedy]

Thank you for that clarification.  That's sort of what I expected that's extremely helpful for the confirmation so I know what needs to get done.

Does nrf have any sample projects for doing this? 
If not, I imagine the ncs/bootloader/mcuboot/boot folder has some source code I could port into my application

[Amanda Hsieh]

Unfortunately, there is no sample for that.

-Amanda H. 

[Roedy]

For anyone attempting to do this, it is possible.

With direct XIP mode, the update image must be stored in external flash.

You will need a method to write the image file into external flash.  The file to use is build/zephyr/net_core_app_update.bin

mcuboot locks the PCD ram permanently before booting.  This must be disabled.  Search through the bootloader code for the call to "pcd_lock_ram()" and comment it out, or you can modify that function to not lock the ram permanently

To perform an update, the minimal steps from the application are

• copy the net_core_app_update.bin file from external flash to the secondary slot
• call pcd_network_core_update (see the bootloader loader.c file for example)
• reboot the system

The actual number of steps will vary depending on if you lock the ram, if you want to verify your images before/after transferring them, if you want to backup and restore the secondary firmware slot, and I'm sure that I'm missing steps.

If you can avoid this, I recommend that you do.