NRF5340 MCUboot is incompatible with PacketCraft and Large Application

RE: NRF5340 MCUboot is incompatible with PacketCraft and Large Application

ernieforzano — Thu, 17 Aug 2023 16:52:19 GMT

Hi!

We figured it out!! For anyone who needs an answer for this, there are two main options for the NRF5340 with MCUboot and your application is large (larger then the allowed 400k for both slot0 and slot1) and we needed USB as well:

need to be able to update just the application core (CONFIG_SINGLE_APPLICATION_SLOT)
need to update the the application and network core (CONFIG_SINGLE_APPLICATION_SLOT and CONFIG_NRF53_RECOVERY_NETWORK_CORE)

For, the first option you should be able to use this example USB_CDC or the serial example. (There are a number of options, waiting for boot, button, USB in these examples.)

For the second option, there are a few things you will have to do. For most of this we are mainly combining the files for mcuboot_serial_recovery_cdc_acm and mcuboot_netcore_serial_recovery examples:

For your prj.conf include

CONFIG_BT=y
CONFIG_MCUBOOT_IMAGE_VERSION="0.0.0+0"
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y
CONFIG_USB_CDC_ACM=y
CONFIG_LOG=n
CONFIG_LOG_MODE_MINIMAL=y

For your child_image/mcu_boot.conf

#
# Copyright (c) 2022 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

CONFIG_MAIN_STACK_SIZE=10240
# Flash
CONFIG_FLASH=y

# Enable MCUboot Serial Recovery
CONFIG_MCUBOOT_SERIAL=y
CONFIG_UART_CONSOLE=n
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_SINGLE_APPLICATION_SLOT=y

# MCUBoot serial
CONFIG_MCUBOOT_SERIAL=y
CONFIG_MCUBOOT_SERIAL_DIRECT_IMAGE_UPLOAD=y

# Point Serial Recovery to CDC_ACM
CONFIG_BOOT_SERIAL_CDC_ACM=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

# Decrease memory footprint
CONFIG_CBPRINTF_NANO=y
CONFIG_TIMESLICING=n
CONFIG_BOOT_BANNER=n
CONFIG_CONSOLE=n
CONFIG_CONSOLE_HANDLER=n
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=n
CONFIG_USE_SEGGER_RTT=n
CONFIG_LOG=n
CONFIG_RESET_ON_FATAL_ERROR=n

# The following configurations are required to support serial recovery of the
# network image
CONFIG_PCD_APP=y

CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n

CONFIG_BOOT_IMAGE_ACCESS_HOOKS=y
CONFIG_NRF53_RECOVERY_NETWORK_CORE=y
CONFIG_MCUBOOT_INDICATION_LED=y

We needed USB so we included pm_static.yml for increasing the size for the USB_CDC

mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000

Edit the CMAKE for C:\ncs\v2.4.0\nrf\modules\mcuboot\CMakeLists.txt and put (this is where we messed up before because we needed to put network core starting address which we found was 0x1008800. We used a slot size of 0x40000 of the primary_bootloader1). This should get you passed the img_tool.py error.
If you are using packet craft (NRF5340 audio binary), you have two more steps:
1. Edit the \tools\buildprog\ble5-ctr-rpmsg_sign.py (the size of our slot, because its hardcoded to look for the secondary slot, which we don't want or need).
2. When building your audio application, we found creating and building the audio example with CONFIG_BOOTLOADER_MCU enabled was easiest to getting the MCUBOOT firmware update file.
  1. NOTE: You may have to edit the nrf5340_audio\dfu\conf\Kconfig.dfu to
    
    AUDIO_DFU to 1 and
    
    B0N_MINIMAL to y.
  2. Once you build you will have a file build\ble5-ctr_net_core_update.bin
    1. This is the way to update the network core.
Finally, we can update our device over the mcumgr. Reset your device and hold down your button or your preferred way to get it into boot loader mode then:
1. for updating your application
  1. mcumgr --conntype serial --connstring COM49 image upload -e build\zephyr\app_update.bin -n 1
2. for updating your network core
  1. mcumgr --conntype serial --connstring COM49 image upload -e build\zephyr\net_core_app_update.bin -n 3

We are now done!! Hope this helps anyone in the same predicament.

RE: NRF5340 MCUboot is incompatible with PacketCraft and Large Application

Hieu — Wed, 16 Aug 2023 22:01:21 GMT

[quote user="ernieforzano"]Yeah that is what we figured, but is there not a way to direct upload? Like use CONFIG_BOOT_UPGRADE_ONLY=y. [/quote]

Unfortunately, no. MCUboot lies on the application core and manage the serial recovery process, but it doesn't have access to the network core flash. Thus, the process always involves copying the image to shared RAM, after which the Network core bootloader (AKA netboot, AKA b0n) on the network core will then copy the image to the flash memory using Peripheral CPU DFU (PCD).

[quote user="ernieforzano"]Sweetness! So I was using the same strategy of CONFIG_SINGLE_APPLICATION_SLOT and nRF53 Network Core Serial Recovery. I was able to compile it by finding there is a file C:\ncs\v2.4.0\nrf\modules\mcuboot\CMakeLists.txt that is auto generating a command for the imgtool.py. The slot size and the start address offset gets hardcoded to the secondary partition. I modified is so that it used the slot size of mcu_boot_primary_1 and its start address offset. [/quote]

Great finding. I am not very knowledgeable with this area and could not find it at all.

I followed your tip and was too able to build successfully.

[quote user="ernieforzano"]I am now able to compile and run the network and application core, run mcuboot in serial recovery mode, and update the application!!

Whenever, I try to update the network core it seems like it gets in an unhappy state. Should I be able to update the network core with mcuboot in this scenario??[/quote]

Since you successfully updated the application core, I skipped it. I hope it's OK.

Conceptually you should be able to. What kind of issue did you encounter? Did you remember to, before resetting, leave the device alone for ~30 seconds after the upload so that PCD can finish updating flash memory?

I also run several attempts at it. My experiment is based on the Bluetooth: Beacon sample, and I can see that after the netcore update, the sample runs as intended. However, the printk() line I added to hci_rpmsg main.c doesn't work post update, which leads me to think that even though it is working, it is probably not reliable. I am thus unsure what is on the network core. It could be either the old image or the new image, but it certainly is not working correctly, and thus is unreliable.

I already let our R&D know of your progress two days ago, but they have been too busy to follow up. I will update them after this with my progress as well, at the same time check if they can help now.

RE: NRF5340 MCUboot is incompatible with PacketCraft and Large Application

ernieforzano — Mon, 14 Aug 2023 14:59:26 GMT

[quote userid="9456" url="~/f/nordic-q-a/102714/nrf5340-mcuboot-is-incompatible-with-packetcraft-and-large-application/441148"]It is not possible to shrink the secondary partition. It is supposed to be large enough to completely hold another copy of the application image. This is required in a dual-slot setup to provide features like image testing or verification.[/quote]

Yeah that is what we figured, but is there not a way to direct upload? Like use CONFIG_BOOT_UPGRADE_ONLY=y.

Sweetness! So I was using the same strategy of CONFIG_SINGLE_APPLICATION_SLOT and nRF53 Network Core Serial Recovery. I was able to compile it by finding there is a file C:\ncs\v2.4.0\nrf\modules\mcuboot\CMakeLists.txt that is auto generating a command for the imgtool.py. The slot size and the start address offset gets hardcoded to the secondary partition. I modified is so that it used the slot size of mcu_boot_primary_1 and its start address offset.

I am now able to compile and run the network and application core, run mcuboot in serial recovery mode, and update the application!!

Whenever, I try to update the network core it seems like it gets in an unhappy state. Should I be able to update the network core with mcuboot in this scenario??

I am flashing the same application with modifying the network and application output to test.

Thanks for the help!

RE: NRF5340 MCUboot is incompatible with PacketCraft and Large Application

Hieu — Mon, 14 Aug 2023 12:20:05 GMT

It is not possible to shrink the secondary partition. It is supposed to be large enough to completely hold another copy of the application image. This is required in a dual-slot setup to provide features like image testing or verification.

Fundamentally, if the secondary slot cannot fit an application, then there is no point to it at all.

For the past few days, I have looked into combining CONFIG_SINGLE_APPLICATION_SLOT and nRF53 Network Core Serial Recovery, which should essentially give us what we need. However, I am completely stuck at an error where the build system cannot generate the proper imgtool.py command. It's likely that it is not prepared to handle this setup.

I have informed our engineer about this issue, and they will work on it. Unfortunately, I cannot comment on when they will fix it.

At 920 kB, I am not certain how much impact optimization can help. However, have you looked at optimizing the memory footprint?

We have a short guide for that here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.1/nrf/app_dev/optimizing/memory.html.

RE: NRF5340 MCUboot is incompatible with PacketCraft and Large Application

ernieforzano — Thu, 10 Aug 2023 14:27:06 GMT

We are okay with any solution that upgrades network and application core. We don't necessarily need CONFIG_SINGLE_APPLICATION_SLOT, but thought it was close.

We just want to be able to upgrade the application and network cores through USB and it seems MCUboot requires large slots for the primary (main application) and secondary (for network).

Is there anyway to shrink these down through pm_static.yml? Or any other way that could be useful?

Thank you for your response!

RE: NRF5340 MCUboot is incompatible with PacketCraft and Large Application

Hieu — Thu, 10 Aug 2023 13:34:42 GMT

Hi ernieforzano,

As I am coincidentally also working on another question about getting CONFIG_SINGLE_APPLICATION_SLOT for the nRF5340, I will be supporting you with this case.

Right now, I am still trying to get it to work. I will keep you updated about the progress. I hope a little wait is not too much inconvenient.

Hieu