Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Jason — Mon, 16 Oct 2023 01:43:12 GMT

Thanks, I hope so. However, I am still facing the issue when enabling the ANT+ features. Waiting for the feedback from Nordic😔.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Fri, 13 Oct 2023 07:38:36 GMT

I'm glad it works for you and I hope that you never have to touch the update related code again 🙂

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Jason — Fri, 13 Oct 2023 02:36:56 GMT

[quote userid="85343" url="~/f/nordic-q-a/102767/confusion-about-multi-image-dfu-on-nrf5340-in-nrf-connect-sdk-2-4-1-yes-again/450045"]I *think* that the main problem in your scenario is that you're also erasing the network core bootloader (b0n).[/quote]

Thank you for pointing out the problem, now the network core can be recovered after I program the b0n.

[quote userid="85343" url="~/f/nordic-q-a/102767/confusion-about-multi-image-dfu-on-nrf5340-in-nrf-connect-sdk-2-4-1-yes-again/450045"]Of course, in this scenario you shouldn't get a PCD_STATUS_COPY[/quote]

I think this is similar to the issue(nrf5340 net core upgrade) I posted before.

[quote userid="85343" url="~/f/nordic-q-a/102767/confusion-about-multi-image-dfu-on-nrf5340-in-nrf-connect-sdk-2-4-1-yes-again/450045"]Also, I think that this whole thing could've been done better without the need for a separate bootloader on the network core (for example by running code only from RAM when updating the network core)[/quote]

Yes, this should be a better way. but for me, it is enough for the current requirement, I mean request a b0n on the network core. you know, changing the default upgrade mechanism is a headache.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Thu, 12 Oct 2023 12:03:16 GMT

If I'm reading your description correctly, I *think* that the main problem in your scenario is that you're also erasing the network core bootloader (b0n). You're also not specifying how you're programming MCUboot after you erase the appliication core (or maybe you donn't erase MCUboot at all?). Of course, in this scenario you shouldn't get a PCD_STATUS_COPY, so there are multiple problems here, but at some point I'd like to try to erase the network core minus its bootloader and test your scenario. Also, I think that this whole thing could've been done better without the need for a separate bootloader on the network core (for example by running code only from RAM when updating the network core), but this is a separate discussion.

As for ANT+, I never used that, so unfortunately I don't have any insights there.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Jason — Thu, 12 Oct 2023 11:12:27 GMT

Thanks!

[quote userid="85343" url="~/f/nordic-q-a/102767/confusion-about-multi-image-dfu-on-nrf5340-in-nrf-connect-sdk-2-4-1-yes-again/449980"]Note that I don't know if these are all needed, but I got a working configuration and I don't plan on touching it again, because it appears to be very fragile. Finding the right configuration for this feature was an absolute nightmare, way too many options that need to be set in too many places.[/quote]

yes, my configuration is similar to yours, the configuration was an absolute nightmare.

Unfortunately, I got "Network core update FAILED", and I found that it was due to enabling the ANT+ features, I encountered a similar issue when updating the network core by BLE, and I got a fix, but unfortunately this fix doesn't seem to work in the recovery mode.

I created a test project without the ANT+ feature and was able to update the network core in recovery mode, but I found an interesting phenomenon.

Test as below:

1. erase the application core and network core

2. only program the application core

3. enter recovery mode, upload the net_core_app_update.bin

4. after uploading completely, pcd_fw_copy_status_get() always returns PCD_STATUS_COPY

That means the network core can not be recovered if the current network core is not working.

If my finding is correct, then What's the point of recovery mode?

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Thu, 12 Oct 2023 08:23:55 GMT

Hi,

I have CONFIG_UPDATEABLE_IMAGE_NUMBER=2, but this must be in the main prj.conf, NOT in child_image/mcuboot.conf (at least that's my experience with this particular option). Other related options that I have in prj.conf:

CONFIG_MCUMGR_MGMT_NOTIFICATION_HOOKS=y
CONFIG_MCUMGR_GRP_IMG_UPLOAD_CHECK_HOOK=y

I also have these in child_image/mcuboot.conf (assuming that your board has external QSPI flash):

# Simultaneous multi-image update
CONFIG_NRF53_MULTI_IMAGE_UPDATE=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16
CONFIG_FLASH=y
CONFIG_SOC_FLASH_NRF_EMULATE_ONE_BYTE_WRITE_ACCESS=y
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y

Note that I don't know if these are all needed, but I got a working configuration and I don't plan on touching it again, because it appears to be very fragile. Finding the right configuration for this feature was an absolute nightmare, way too many options that need to be set in too many places.

Slot numbers (-s option for mcumgr):

- app core: 0 in normal mode, 1 in recovery mode
- net core: 1 in normal mode, 3 in recovery mode.

(yes, they are different. As if this whole thing wasn't confusing enough).

Also note that in recovery mode you won't get a message from MCUboot after the update is complete, I'm using the following patch to fix this issue:

---
 subsys/pcd/src/pcd.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/subsys/pcd/src/pcd.c b/subsys/pcd/src/pcd.c
index b22a8975a..34b48dfeb 100644
--- a/subsys/pcd/src/pcd.c
+++ b/subsys/pcd/src/pcd.c
@@ -125,12 +125,18 @@ static void network_core_pcd_tidy(void)

 static void network_core_finished_check_handler(struct k_timer *timer)
 {
-	if (pcd_fw_copy_status_get() != PCD_STATUS_COPY) {
+	enum pcd_status status = pcd_fw_copy_status_get();
+	if (status != PCD_STATUS_COPY) {
 		/* Upgrade has finished and either failed or completed
 		 * successfully, tidy up and cancel timer
 		 */
 		k_timer_stop(&network_core_finished_check_timer);
 		network_core_pcd_tidy();
+		if(status == PCD_STATUS_COPY_DONE) {
+			LOG_INF("Network core update done");
+		} else {
+			LOG_ERR("Network core update FAILED!");
+		}
 	}
 }

I hope this helps!

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Jason — Thu, 12 Oct 2023 02:53:46 GMT

Hi Bogdan,

I am facing the same issue. I am able to update the network core and application core by BLE, and also the recovery of the application core image, but can not update the network core in recovery mode.

Could you tell me the steps of how to make both simultaneous update and serial recovery work?

e.g what is the MCUBoot conf?

CONFIG_UPDATEABLE_IMAGE_NUMBER=?

CONFIG_NRF53_MULTI_IMAGE_UPDATE=?

CONFIG_NRF53_RECOVERY_NETWORK_CORE=?

what is the mcumgr command?

Thanks!!

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Thu, 17 Aug 2023 16:34:45 GMT

Hi Hieu. Yes, everything is OK now, this ticket can be closed. Thank you.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Hieu — Thu, 17 Aug 2023 15:43:28 GMT

Hi Bogdan,

Thank you for the feedback. I will relay them to our R&D.

From your updates, I understand that both simultaneous update and serial recovery are working for you now. Is that right?

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Tue, 15 Aug 2023 12:18:48 GMT

One more thing relateed to this: I've noticed that there's no indication that the network core update finished in serial recovery mode when CONFIG_NRF53_MULTI_IMAGE_UPDATE is enabled (and there really should be one). The bootloader will just display this on the console after the net core image is uploaded:

[...]
I: Erasing range 0x2e000:0x2efff
I: Writing at 0x2dd80 until 0x2e888
I: Erasing range 0x39000:0x39fff
I: Turned on network core
I: RX: 0x0
I: TX

That's all the information what we get about the net core update. I added this patch to my source tree (this is on top of NCS 2.4.1):

diff --git a/subsys/pcd/src/pcd.c b/subsys/pcd/src/pcd.c
index b22a8975a..34b48dfeb 100644
--- a/subsys/pcd/src/pcd.c
+++ b/subsys/pcd/src/pcd.c
@@ -125,12 +125,18 @@ static void network_core_pcd_tidy(void)

static void network_core_finished_check_handler(struct k_timer *timer)
{
- if (pcd_fw_copy_status_get() != PCD_STATUS_COPY) {
+ enum pcd_status status = pcd_fw_copy_status_get();
+ if (status != PCD_STATUS_COPY) {
/* Upgrade has finished and either failed or completed
* successfully, tidy up and cancel timer
*/
k_timer_stop(&network_core_finished_check_timer);
network_core_pcd_tidy();
+ if(status == PCD_STATUS_COPY_DONE) {
+ LOG_INF("Network core update done");
+ } else {
+ LOG_ERR("Network core update FAILED!");
+ }
}
}

I'm sure there are better ways to do this (ideally the status should be reported to mcumgr), but at least this gives a visual indication of what happened with the net core upgrade.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Tue, 15 Aug 2023 09:32:03 GMT

Hi Hieu, thanks for the reply. I left out the -e and -c arguments because they were sort of implied for this use case, the important part is the -n which specifies the image ID. Section "The MCUboot’s serial recovery of the networking core image" of https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/device_guides/working_with_nrf/nrf53/nrf5340.html shows that this argument should be 3, but this information is not present in the "Simultaneous multi-image DFU" section of the same document and I didn't know if the image number is correct for the latter case. Some experiments suggests that it is, but I still think that this deserves a more clear explanation.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Hieu — Mon, 14 Aug 2023 07:28:05 GMT

Sorry, I meant to link the following guide in my previous reply. It is where the documentation screenshot comes from:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.1/nrf/working_with_nrf/nrf53/nrf5340.html#mcuboot-s-serial-recovery-of-the-networking-core-image

You can see the mcumgr command you need documented there. Looks like you are only missing the -e and -c serial_conn arguments.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Fri, 11 Aug 2023 14:08:33 GMT

Thank you. So then what parameters do I need to give mcumgr to update the network core in recovery mode when CONFIG_NRF53_MULTI_IMAGE_UPDATE is enabled? I expect that even if I enable CONFIG_NRF53_MULTI_IMAGE_UPDATE (which is a "simultaneous multi-image DFU" mode) I still need to upload the images for the app core and the net core separately in serial recovery mode? In that case, would mcumgr image upload -n 3 build//zephyr/net_core_app_update.bin be the correct invocation?

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Hieu — Fri, 11 Aug 2023 13:50:17 GMT

Hi Bogdan,

If your goal is to have both multi-image update and serial recovery of both cores possible, then all you need is CONFIG_NRF53_MULTI_IMAGE_UPDATE. You can see it mentioned here:

To setup serial recovery over USB CDC instead of UART, you can refer to Hellesvik's sample. Even though it is for NCS v2.3.0, it should still be applicable to NCS v2.4.x.

Refer: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/blob/v2.3.0/bootloader_samples/serial_recovery/mcuboot_serial_recovery_cdc_acm/child_image/mcuboot.conf#L4-L9

# Enable MCUboot Serial Recovery
CONFIG_MCUBOOT_SERIAL=y
CONFIG_UART_CONSOLE=n

# Point Serial Recovery to CDC_ACM
CONFIG_BOOT_SERIAL_CDC_ACM=y

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Bogdan Marinescu — Fri, 11 Aug 2023 12:50:49 GMT

Hi Hieu, thanks for your reply. That phrase can be understood both ways, but the Kconfig definition of NRF53_RECOVERY_NETWORK_CORE does make things clear. However, I think I didn't explain my original issue clearly enough. I don't really care if I can enable NRF53_RECOVERY_NETWORK_CORE and NRF53_MULTI_IMAGE_UDPATE at the same time, all I care about is to have a way to use DFU on both cores on BLE and USB CDC (recovery mode), whatever the config option(s) are. The link in my original post (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/device_guides/working_with_nrf/nrf53/nrf5340.html#simultaneous-multi-image-dfu) does not state if it is possible to use USB CDC when NRF53_MULTI_IMAGE_UDPATE is enabled and how to do that with mcumgr if it is. That is the part that I'm interested in.

RE: Confusion about multi-image DFU on nRF5340 in nRF Connect SDK 2.4.1 (yes, again)

Hieu — Fri, 11 Aug 2023 12:43:32 GMT

Hi Bogdan,

Regarding this line

[quote user=""]"To enable the serial recovery of the network core while the multi-image update is not enabled in the MCUboot [...]"[/quote]

Could you please take another look at it? It is about enabling serial recovery of network core "while the multi-image update is not enabled in MCUboot."

The way I understand it is the opposite of what you said. I read it as a guide to enabling serial recovery but when multi-image update is disabled.

This does not contradict with the Kconfig definition.

I have relayed your interest to enable both feature at the same time with our engineers. However, as a support engineer on DevZone, I cannot comment on when that feature would be possible. My apology for the inconvenience.

Hieu