Update custom net core image on nrf5340 with NCS v2.7.0 using external SPI flash

[sachrmed]

Hello,

I've spend some time updating our nrf5340 application to NCS v2.7.0, including using the new hardware model and using sysbuild. We have a custom application that we are running on the network core.
It seems that mcuboot, b0, and both our applications for the app core and net core all build and run.

We have an external SPI flash that we would like to use for the secondary image slot for both the app and net core image.

So far, I'm able to get the app core updated via Bluetooth with SMP, but I'm not able to upgrade the network core.

If I try to send the file signed_by_mcuboot_and_b0_net_app.bin, the device just boot loops. My guess is that mcuboot copied this image meant for the net core onto the app core.

I've seen lots of information about simultaneous updates to both net core and app core. This isn't too much of a concern for me and I'm ok updating each core individually from different files. That is how it worked before in the previous version of our SDK (v2.1.0). In that version, there was a single secondary slot in internal flash that either the app core or net core image would be downloaded to. mcuboot would then somehow know whether to copy it to the app or net core. That no longer seems to be the case when using the external flash on the new SDK.

(I'm not opposed to supporting simultaneous updates if that's the only way to do it)

To simplify things, I've tried several samples to try and get this working, including nrf5340_audio, light_switch (modified to allow SMP over Bluetooth), and smp_svr. They were all quite a chore to even build, but they all also fail to let me update the network core.
I tried the advice given in this post to modify the smp_svr app for a nrf5340dk, and it also just boot loops when I try to update the net core.

Are there any sample projects that include all of:
1. Secondary slot for app and net core on external flash

2. Updateable network core

3. Custom network core firmware

?

Sorry for the long post, but I'm having a difficult time figuring out what is and isn't supported and how one can go about getting this to work. Is there a basic sample that can demonstrate updating the net core from a secondary slot on external flash?

Thanks very much!

[ykavi]

Any possible solutions to this would be appreciated. I’ve been facing the same exact problem for a while and have been looking for a solution.

Thank you. 

[Vidar Berg]

Hello,

Sorry for the delayed response. I'm not aware of any samples in v2.7.0 that do exactly this, so I will try to create a small demo to see if I can get it to work. Before starting, could you please confirm whether you use encrypted DFU images or not? I know  the detection mechanism used to determine if the image in the secondary slot belongs to the app or netcore does not work with encrypted images.

Best regards,

Vidar

ykavi said:

Any possible solutions to this would be appreciated. I’ve been facing the same exact problem for a while and have been looking for a solution.

Could you please confirm if your application has the exact same requirements as OP? i.e., non-simultaneous DFU, external SPI flash, and B0n + MCUBoot bootloader with SDK v2.7.0?

[sachrmed]

No problem! Thanks for the reply.

Currently I'm trying with non-encrypted images. We are using signed images though.
Encryption could be an option in the future, but we can keep it simple for now

I'm looking forward to seeing your sample!

[Vidar Berg]

Unfortunately, one of the developers has confirmed that it's currently not possible to update the network core from external flash unless simultaneous updates are enabled. Do you have any existing devices that need to be updated? The reason I ask is that it's not possible to change the memory layout through DFU.

Attached below is the simultaneous DFU demo sample I created. It uses the nRF immutable bootloader (B0) + MCUBoot, and SPI flash for the secondary DFU slots. Is tested on a nRF5340DK.

0410.peripheral_lbs_ble_fota.zip

Limitations:

- This patch: https://github.com/nrfconnect/sdk-nrf/pull/16894 needs to be applied to the 'nrf' repo to allow the signing key for mcuboot (SB_CONFIG_BOOT_SIGNATURE_KEY_FILE) to be set with a path relative to the project directory.

- The mcuboot, application, and netcore image need to be updated and confirmed individually from the advanced menu in the nRF Device Manager app on iOS/Android. 

[sachrmed]

Hi Vidar,

Thanks very much for putting that together.

Vidar Berg said:

Do you have any existing devices that need to be updated? The reason I ask is that it's not possible to change the memory layout through DFU.

Fortunately we are still in development so we have the freedom to make these changed right now.

I also have a nRF5340DK that I have used to try out your sample.
I built it using the nRF Connect VS Code extension. I set up the build for a nrf5340dk/nrf5340/cpuapp and selected "Use sysbuild".

After flashing, I placed the generated dfu_application.zip onto my phone and opened it with the nRF Device Manager app.

It looks like it was able to send the file, but the console of my nrf5340dk printed out the following:

I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
E: Failed to open flash area ID 2: -2
I: Image index: 1, Swap type: none
I: Erased 0x2c000 bytes of image slot
I: Erased 0x4000 bytes of image slot trailer
E: Failed to open flash area ID 2: -2
I: Image index: 1, Swap type: none
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
E: Failed to open flash area ID 2: -2

I'm a bit concerned about those flash errors. Is that expected?
Also, how can I confirm that the upgrade was indeed successful?

Thanks again!

[Vidar Berg]

Hi,

sachrmed said:

It looks like it was able to send the file, but the console of my nrf5340dk printed out the following:

The 'mcuboot_primary_1' RAM partition is not accessible from the application, which causes an error when the mcumgr client attempts to read the state of each MCUBoot slot (you can find which ID a given flash partition is mapped to from the generated pm_config.h file). This error message can safely be ignored.

sachrmed said:

Also, how can I confirm that the upgrade was indeed successful?

One way to verify if the application is updated is to print the app version string by adding the following code to main.c (version string is generated from the VERSION file located in the project root):

#include <app_version.h>

...

int main(void)
{
	int blink_status = 0;
	int err;

	//MOD: print version string on startup
	printk("Starting Bluetooth Peripheral LBS example %s\n", 
		APP_VERSION_STRING);
	...
	

Log showing a successful update:

Starting Bluetooth Peripheral LBS example 1.1.0
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, f98
I: data wra: 0, ac
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF53x (0x0003)
I: Firmware: Standard Bluetooth controller (0x00) Version 214.51162 Build 1926957230
I: No ID address. App must call settings_load()
Bluetooth initialized
I: Identity: C4:B5:E5:CB:42:EF (random)
I: HCI: version 5.4 (0x0d) revision 0x21fb, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x21fb
Advertising successfully started
Connected
Security changed: 78:64:C0:20:53:23 (public) level 4
W: Ignoring data for unknown channel ID 0x003a
I: Image index: 0, Swap type: none
I: Erased 0x25000 bytes of image slot
I: Erased 0x1000 bytes of image slot trailer
I: Image index: 0, Swap type: none
I: Image index: 1, Swap type: none
E: Failed to open flash area ID 2: -2
I: Image index: 0, Swap type: none
I: Image index: 0, Swap type: perm
I: Image index: 1, Swap type: perm
E: Failed to open flash area ID 2: -2
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0xd2...10
Firmware signature verified.
Firmware version 2
*** Booting MCUboot v2.1.0-dev-daf2946a0f07 ***
*** Using nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
I: Starting bootloader
I: Image index: 0, Swap type: perm
I: Image index: 1, Swap type: none
I: Image 0 upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Image 0 copying the secondary slot to the primary slot: 0x245f0 bytes
I: Bootloader chainload address offset: 0x28000
�I: mx25r6435f@0: 8 MiBy flashslot
*** Booting My Application v1.2.0-f8c506039b0b ***
*** Using nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
Starting Bluetooth Peripheral LBS example 1.2.0
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, f80
I: data wra: 0, c8
I: HW Platform: Nordic Semiconductor (0x0002)
I: HW Variant: nRF53x (0x0003)
I: Firmware: Standard Bluetooth controller (0x00) Version 214.51162 Build 1926957230
I: No ID address. App must call settings_load()
Bluetooth initialized
I: Identity: C4:B5:E5:CB:42:EF (random)
I: HCI: version 5.4 (0x0d) revision 0x21fb, manufacturer 0x0059
I: LMP: version 5.4 (0x0d) subver 0x21fb
Advertising successfully started

Updating application image with nRF Device manager app on iOS from the advanced menu:

Select which binary to upload (peripheral_lbs.bin in this case):

After uploading, read the image slots and confirm that the new image in the secondary slot has a higher version number.

Then confirm the update by pressing 'confirm'. After confirming the image, you can send the reset command to have the bootloader activate the update.

[sachrmed]

Hi Vidar,

That was very helpful.

I was able to port the relevant changes over to my application and I am now able to update both the app core and net core.

I think part of the confusion is that we are used to using the nRF Connect phone app to send .bin files for update, and that was working with version 2.1.0 of the SDK.

It appears that nRF Connect always sets the SMP "image" field of the Image Upload request to 0. Device Manager, on the other hand, sets "image" to 0 for the app core and sets it to 1 for the net core.

We have a custom SMP application here that I was able to experiment with. It appears that you can indeed update only the app core or net core so long as you send the .bin file with the correct "image" field. So it seems it's possible to update only one of the cores or both at the same time. I'm not sure if this behaviour is documented anywhere.

Thanks again for your help!