Serial recovery freezes when updating Network core

[evanperryg-somewear]

I have been trying to get DFU working on an nRF5340-based custom board. I want to be able to update the network core and application over USB using mcumgr. I would also like to be able to update the network core over Bluetooth, but the USB serial capability is more important.

I am using NCS 2.3.0.

Here is MCUBoot's configuration:

CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_BOOT_SERIAL_DETECT_DELAY=5000
CONFIG_BOOT_SERIAL_MAX_RECEIVE_SIZE=4096
CONFIG_BOOT_SERIAL_UNALIGNED_BUFFER_SIZE=128

# *snip*

CONFIG_PCD_APP=y
CONFIG_NRF53_MULTI_IMAGE_UPDATE=y
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n
CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_BOOT_UPGRADE_ONLY=y

# *snip*
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x14000
CONFIG_MAIN_STACK_SIZE=10304
CONFIG_BOOT_MAX_IMG_SECTORS=256

My application has the following configuration:

CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y
CONFIG_MCUMGR_MGMT_NOTIFICATION_HOOKS=y
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y
CONFIG_MCUMGR_SMP_REASSEMBLY_BT=y

# *snip*

CONFIG_MEMFAULT=y
CONFIG_NEWLIB_LIBC=y
CONFIG_BT=y

# *snip*

I have successfully updated the application firmware using this command:

mcumgr image upload -c dev0 .\build\zephyr\app_update.bin

I am trying to use this command (from Nordic's docs) to update the network core:

mcumgr image upload -c dev0 -n 3 .\build\zephyr\net_core_app_update.bin

Here is the output of mcumgr image list:

Images:
 image=0 slot=0
    version: 3.9.2.0
    bootable: false
    flags:
    hash: Unavailable
 image=1 slot=0
    version: 0.0.0.0
    bootable: false
    flags:
    hash: Unavailable
Split status: N/A (0)

When I run this command, mcumgr's progress bar sits at 0% forever.

How do I make the network core DFU work?

Side note: yesterday, I was trying to make it work without the CONFIG_NRF32_MULTI_IMAGE_UPDATE enabled. the mcumgr command succeeded, but then the network core bootloader was failing - you can find my findings here.

[evanperryg-somewear]

I added CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y  to my mcuboot.conf file, and I was able to upload the network core firmware using this command:

mcumgr image upload -c dev0 -n 3 .\build\zephyr\net_core_app_update.bin

However, now my application crashes because the network core is returning an error.

[00:00:03.620,147] \033[1;31m<err> bt_hci_driver: bt_rpmsg_open: Endpoint binding failed with -11\033[0m
[00:00:03.620,178] \033[1;31m<err> bt_hci_core: bt_enable: HCI driver open failed (-11)\033[0m

[evanperryg-somewear]

Stepping through b0n during the DFU process, it seems like b0n is accepting the image and writing it to flash. I was able to walk through every step of b0n's update process all the way up to the forever loop following this comment: /* Success, waiting to be rebooted */

The PCD command appears to be set to 0xf103ce5d after running mcumgr reset. However, I get the -11 error when I reboot.

I did find a very strange detail, though. If I...

1. Do the network core upgrade. (mcumgr image upload ...)

2. Reset (mcumgr reset)

3. Cut power to the board

4. Plug the board back in and power on

I can see that the updated network core firmware is running, and there is no -11 error.

[AHaug]

Hi,

Apologies for the long reply time. This is due to the Easter holidays in Norway which spanned the previous week. This is an update to let you know I've picked up your case and will be working on finding an answer for you. There might still be some time before I have something constructive for you, but I'll do my best to get back to you within this working week.

In the meanwhile, let me know if you've solved the issue while waiting for a reply.

Kind regards,
Andreas

[AHaug]

Hi,

I've discussed the symptoms you're describing with some colleagues and it looks like it might be that you need to wait a bit more to let PCD do its thing before resetting (30 sec or so). It is however a bit strange that you see that it the network core is updated when you cut the power the latest list of steps you describe.

Can you confirm that the network core update procedure works with the description you gave?

evanperryg-somewear said:

I added CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y  to my mcuboot.conf file, and I was able to upload the network core firmware using this command:

CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y was the other thing we discussed. It is correct that you need to enable this. If not image upload (..) will default to the primary slot even if you do -n 3.

Kind regards,
Andreas

[evanperryg-somewear]

Hello, Andreas:

I was finally able to get things working late last week. In addition to CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD, I tweaked the SDK to add a fix for Anomaly 161. This seems to have resolved the problem I was seeing.

[AHaug]

Thank you for letting us know. I will verify this case for now if there are no other questions. If any should arise at any later point, please feel free to open this case or raise a new issue

Kind regards,
Andreas