nRF5340 simultaneous multi image dfu + serial recovery

[Przemek Ostrowski]

Hi
Is it possible to configure project to use simultaneous multi image DFU and serial recovery over USB? 
I would like to be able to update both cores using dfu_multi_image_XXX and in case something goes wrong, being able to recover both cores (app + net) using mcumgr command line tool.

Thank you in advance.
Przemek

[Amanda Hsieh]

Hi, 

You can refer to this Devacademy course https://academy.nordicsemi.com/simultaneous-updates-for-both-cores-of-the-nrf5340/ and this course https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-4-dfu-over-usb/ 

Regards,
Amanda H.

[Przemek Ostrowski]

I am asking my question because of this link:
https://docs.nordicsemi.com/bundle/ncs-3.0.2/page/nrf/app_dev/device_guides/nrf53/serial_recovery.html

"In addition to the recovery of the application core image, also the networking core image can be recovered. When you build MCUboot for the nRF5340 DK or the Thingy:53, you can use this feature with one of the following options:

• Simultaneous multi-image DFU with nRF5340 DK

• Serial recovery for the network core in the one image pair mode, where sysbuild Kconfig option SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES is set to == 1.

To enable the serial recovery of the network core while the multi-image update is not enabled in MCUboot, set the following Kconfig options in the MCUboot image:"

So it is not clear to me if these configurations are excluding each other?

[Amanda Hsieh]

Przemek Ostrowski said:

So it is not clear to me if these configurations are excluding each other?

Do you see any conflicts? If so, please provide the log.  

[Przemek Ostrowski]

There is no errors, it seams to be working with one exception. I need to be sure it works by design not by accident. So could you please confirm it is meant to work together?

I can update app and radio cores from application code:

dfu_multi_image_init(&multiimageDfuBuffer[0], sizeof(multiimageDfuBuffer));

writer.image_id = 0;

dfu_multi_image_register_writer(&writer);

writer.image_id = 1;

dfu_multi_image_register_writer(&writer);

...

And from MCUBoot:
mcumgr -c acm1 image upload  -e -n 0 ./app/zephyr/zephyr.signed.encrypted.bin
mcumgr -c acm1 image upload ./signed_by_mcuboot_and_b0_ipc_radio.bin -e -n 3


I do not understand why mcumgr command works with -n 3 where dfu_multi_image use 1.
Please confirm it is by design not a bug that will be fixed in the next 6 months and I will be not able recover the firmware in the future.
Thank you.
Przemek

[Amanda Hsieh]

Przemek Ostrowski said:

I do not understand why mcumgr command works with -n 3 where dfu_multi_image use 1.

I think you mean this code https://github.com/nrfconnect/sdk-nrf/blob/main/samples/dfu/dfu_multi_image/src/main.c#L84 

Image ID is 0 for the application core and 1 for the network core. See DFU Multi-image

-n is used for image selection. Here you can find the slot numbers for Serial Recovery:

https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/zephyr/Kconfig.serial_recovery#L63-L67

As you see from this second list, 3 is image-2, which should be the network core image I think. Also see Managing direct image upload.