Using the options described in ncs documentation for one image pair updates (i.e. not multi-image DFU) appears to be broken in ncs 3.0 and later for upgrading the network core. I am currently using ncs 3.2.1 on Linux targetting an nRF5340DK with nrf5340dk/nrf5340/cpuapp. I have attached a minimal project that replicates this: nrf5340dk_dfu_via_serial_recovery.tgz
It appears that the serial bootloader will accept the image file, but the nRF53 hook to signal the network core fails to fire. If you attach the debugger in mcuboot to nrf/modules/mcuboot/hooks/nrf53_hooks.c:
int boot_serial_uploaded_hook(int img_index, const struct flash_area *area,
size_t size)
{
if (img_index == NET_CORE_VIRTUAL_PRIMARY_SLOT) {
return network_core_update(false);
}
return 0;
}
When the hook is called after the network core image is uploaded, you will find that the image index of "3" for the network core is correctly passed along, but it turns out that NET_CORE_VIRTUAL_PRIMARY_SLOT is equal to -1, because of its definition further up in the file:
#define NET_CORE_VIRTUAL_PRIMARY_SLOT (CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER * 2) + 1
Looking at CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER, it is set to -1 because we are using single app mode for mcuboot, since we are using serial recovery. This would have worked in ncs 2.9, until this commit was introduced for ncs 3.0, which remove checking for the case where CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER is equal to -1.
Manually changing NET_CORE_VIRTUAL_PRIMARY_SLOT to equal 3, as it used to be in ncs 2.9, seems to allow me to upgrade the network core.
Are you able to clear up if there's a misunderstanding or misconfiguration on my end, please? I have tried manually setting MCUBOOT_NETWORK_CORE_HAS_UPDATE_SLOT so that the sysbuild script will assign CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER the correct value of 1, and doing so causes the number of updateable images to increase to 2, which breaks other parts of the build.
My production use-case is where the nRF5340 is a co-processor to another processor, and thus the nRF5340 can be safely recovered from image corruption by the main processor even if upgrade process was interrupted halfway through. I would like to use the full flash space of the nRF5340, rather than divide it into primary/secondary regions for a safe upgrade, thus serial recovery over DFU is an ideal solution.
