NRF5340 MCUboot is incompatible with PacketCraft and Large Application

[ernieforzano]

We finished our application on the NRF5340 and need to do firmware updates and are unable due to the current criteria: 

1. NRF53 firmware update over USB CDC ACM (which needs at least 0x10000 rather than 0xC000)
2. Our application is large and is over 920KB (which needs large primary slot)
3. Packet craft network core

We found many unopen tickets about MCUboot forcing having a secondary partition and crashing on the slot size despite using the config CONFIG_SINGLE_APPLICATION_SLOT. This would be perfect for our application, because we are okay with setting it into recovery mode. 

We also tried to look into editing the pm_static.yml file but found on editing that the device crashes on boot even giving proper space. 

Please advise on how we can use packet craft on the network core, doing firmware updates on USBCDC, and having a large application. 

Thank you for your time!

[Hieu]

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

[ernieforzano]

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!

[Hieu]

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.

[ernieforzano]

Hieu said:

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.

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!

[Hieu]

ernieforzano said:

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

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).

ernieforzano said:

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. 

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.

ernieforzano said:

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??

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.

[ernieforzano]

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:

1. need to be able to update just the application core (CONFIG_SINGLE_APPLICATION_SLOT)
   
   
2. 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:

1. For your prj.conf include 

   1. 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

2. For your child_image/mcu_boot.conf

   1. #
      # 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

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

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

4. 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. 
   1. 
5. 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).
      1. 
   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. 
6. 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.