MCUBoot on nrf5340: only upgrade firmware on application core

[Yanpengwu]

Hi Support team,

I encountered some flash overflow errors when I enabled the MCUboot on nrf5340. Could I ask several questions?

My situations and requirements:
1. My project is based on nrf5340 and NCS V2.5.2, the network core was only used for BLE controller (runs hci_rpmsg child image).
2. Before enabling MCUboot, the flash consumption is below:

           

3. I only need to upgrade the firmware on the application core because I use BLE for system configuration, and there is no need to upgrade the network core. The upgrade mode should be "swap" to support firmware rollback when the DFU fails.

Considering my current bin on the application core is 313.9KB, I believe the primary flash (1MB) can meet my requirement. 

When I set partitions in pm_static.yml like below

mcuboot:
address: 0x0
size: 0xC000 # 48 KB Bootloader

slot0:
address: 0xC000
size: 0x64000 # 400 KB Primary Slot

slot1:
address: 0x70000
size: 0x64000 # 400 KB Secondary Slot

scratch:
address: 0xD4000
size: 0x8000 # 32 KB Scratch

pcd_sram:
address: 0x10000000
size: 0x0 # forbid Netcore PCD

There are some errors occurred:
1. mcuboot flash ordata overflow, if I change mcuboot size to 64K, the error disappears. But I prefer to allocate 48K for
mcuboot and need to minimize MCUboot configuration.

2. I only want to upgrade the application core, but there was some information about the network core in the building log:

Could you help me with the below questions:
1. For my current application bin size 313.9 KB, is the primary flash enough for the solution of MCUboot swap upgrade only for the application core?

2. Could you help me revise a MCUboot configuration that can meet my requirements and consume less than 48KB partition?
My current MCUboot configuration is below:

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE=""
CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP=n
CONFIG_MCUBOOT_BOOTLOADER_MODE_SWAP_WITHOUT_SCRATCH=y
CONFIG_MCUBOOT_ENCRYPTION_KEY_FILE=""
CONFIG_MCUBOOT_GENERATE_UNSIGNED_IMAGE=y
CONFIG_BOOT_BANNER=n
CONFIG_PCD_APP=y
CONFIG_PCD_NET=n

Any guidance is appreciated, thank you very much.

Best regards,
Yanpeng Wu

[Yanpengwu]

When I deleted the code in pm_static.yml, and only set 

CONFIG_BOOTLOADER_MCUBOOT=y in proj.conf (follow the sample C:\ncs\v2.5.2\bootloader\mcuboot\samples\zephyr\hello-world\), the error still occurred:

[AHaug]

Hi,

1. For my current application bin size 313.9 KB, is the primary flash enough for the solution of MCUboot swap upgrade only for the application core?

It should be big enough if you only intend to do what is called "non-simultaneous" dfu of the application core only. You will be left with

1MB - MCUBoot - 2x application - (overheadspace + settings + other custom partitions + swap partition) -> 48k - 2x400k (what you defined it as in the partition map) - ~50k ~<= 1024k, i.e it should fit. 

2. Could you help me revise a MCUboot configuration that can meet my requirements and consume less than 48KB partition?
My current MCUboot configuration is below:

This will depend a bit Here's a couple of additions to your bootloader configurations that can help you reduce the size. 

Yes, you need to add a child_image/mcuboot.conf and /mcuboot.overlay for MCUBoot.

For instance here's a sample of a minimal MCUboot with USB DFU support, you can add the following to <yourproject>/child_image/mcuboot/prj.conf you can add 

#
# Copyright (c) 2024 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
 
CONFIG_PM=n
 
CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"
 
CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_IMAGE=n
 
CONFIG_BOOT_UPGRADE_ONLY=n
CONFIG_BOOT_BOOTSTRAP=n
 
### mbedTLS has its own heap
# CONFIG_HEAP_MEM_POOL_SIZE is not set
 
### We never want Zephyr's copy of tinycrypt.  If tinycrypt is needed,
### MCUboot has its own copy in tree.
# CONFIG_TINYCRYPT is not set
# CONFIG_TINYCRYPT_ECC_DSA is not set
# CONFIG_TINYCRYPT_SHA256 is not set
 
CONFIG_FLASH=y
CONFIG_FPROTECT=y
CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y
### Various Zephyr boards enable features that we don't want.
# CONFIG_BT is not set
# CONFIG_BT_CTLR is not set
# CONFIG_I2C is not set
 
CONFIG_LOG=n
CONFIG_LOG_MODE_MINIMAL=n # former CONFIG_MODE_MINIMAL
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=0
### Use info log level by default
CONFIG_MCUBOOT_LOG_LEVEL_INF=y
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
### Use the minimal C library to reduce flash usage
# 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_USE_SEGGER_RTT=n
CONFIG_LOG=n
CONFIG_ERRNO=n
CONFIG_PRINTK=n
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_SPI=n
CONFIG_SPI_NOR=n
CONFIG_I2C=n
CONFIG_UART_NRFX=n

#THESE TWO WILL DEPEND ON IF YOU NEED THEM OR NOT 
#CONFIG_MCUBOOT_SERIAL=y
#CONFIG_BOOT_SERIAL_CDC_ACM=y
 
# Enable LTO for newer versions of NCS. Introduced in 2.6.0 https://docs.nordicsemi.com/bundle/ncs-2.6.3/page/kconfig/index.html#CONFIG_LTO 
#CONFIG_ISR_TABLES_LOCAL_DECLARATION=y
#CONFIG_LTO=y

In <yourproject>/child_image/mcuboot/mcuboot.overlay, you can add the following (if you're using USB to do dfu. If not, just remove those items regarding CDC_ACM)

/* Copyright (c) 2024 Nordic Semiconductor ASA
*
* SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
*/
 
/ {
    chosen {
        zephyr,code-partition = &boot_partition;
    };
};
 
 
/* The USB is used only for MCUboot serial recovery over CDC ACM class.
* Reduce number of endpoints to save memory.
*/
#&usbd {
#    compatible = "nordic,nrf-usbd";
#    status = "okay";
#    num-bidir-endpoints = <0>;
#    num-in-endpoints = <3>;
#    num-out-endpoints = <2>;
#    num-isoin-endpoints = <0>;
#    num-isoout-endpoints = <0>;
#};
 
#&zephyr_udc0 {
#    cdc_acm_uart0: cdc_acm_uart0 {
#        compatible = "zephyr,cdc-acm-uart";
#    };
#};

Let me know if these items helps you reduce the size. You can also have a look at https://docs.nordicsemi.com/bundle/ncs-2.5.2/page/nrf/test_and_optimize.html and https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/, i.e the relevant lessons for 2.5.2 

Kind regards,
Andreas

[Yanpengwu]

Hi Andreas,

Thank you for your reply. Yes, my requirement is to use a "non-simultaneous" DFU, but I only need the first step to upgrade application firmware. The DFU will be over BLE at this moment; over cellular will be considered in the future because there is a modem on our target.

I will follow your guidance to minimize the size of the MCUboot image. I can compile successfully now, but the MCUBoot image is very large, and I have disabled the log.

In my current build result, there are b0n_subimage and net_core_app_update.bin in the dfu_application.zip. Could you help give guidance for disabling the netcore upgrade in "non-simultaneous" dfu (I don't have external flash for DFU) firstly, then I will based on it to minimize the size of MCUboot?

Thank you very much. 

Best regards,
Yanpeng Wu

[AHaug]

Yanpengwu said:

Could you help give guidance for disabling the netcore upgrade in "non-simultaneous" dfu (I don't have external flash for DFU) firstly, then I will based on it to minimize the size of MCUboot?

https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/ and https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-5-fota-over-bluetooth-low-energy/ should go through how to implement non-simultaneous DFU over BLE for only the application core! :) FYI https://academy.nordicsemi.com/simultaneous-updates-for-both-cores-of-the-nrf5340/ goes through simultaneous DFU (with external flash), so you can compare them and see the difference.

This should result in something like the following sample (nonsimultaneous DFU of both cores without internal flash)

6_nrf5340_non_sim.zip

Let me know if you're able to get it up and running using this sample!
Kind regards,
Andreas

[Yanpengwu]

Hi Andreas,

I followed the Exercises and added some configuration:

in prj.conf:
        CONFIG_NRF53_UPGRADE_NETWORK_CORE=n
        CONFIG_UPDATEABLE_IMAGE_NUMBER=1
in child_image\mcuboot.conf:
        CONFIG_NRF53_MULTI_IMAGE_UPDATE=n
        CONFIG_UPDATEABLE_IMAGE_NUMBER=1
        CONFIG_BOOT_UPGRADE_ONLY=y
        CONFIG_PCD_APP=n

The building is successful and the MCUboot image is reduced from 46KB to 35KB, and no b0n_subimage and net_core_app_update.bin, that is what I want, thank you very much.

But after I flash it to our custom board, the output is:

        I: Starting bootloader
        I: Image index: 0, Swap type: none
        E: Unable to find bootable image

Maybe something is wrong? I pasted my current configuration here, could you help review it? Currently I just enable MCUboot, no SMP server etc.
pm_static.yml:

app:
  address: 0x0000c200
  size: 0x00074000          # 464 KB Primary Slot

mcuboot:
  address: 0x00000000
  size: 0x0000c000          # 48 KB Bootloader

mcuboot_pad:
  address: 0x0000c000
  size: 0x00000200          # 512 B

mcuboot_secondary:
  address: 0x00080200
  size: 0x00074000          # 464 KB Secondary Slot

settings_storage:
  address: 0x000f4200
  size: 0x00002000          # 8 KB

scratch:
  address: 0x000f6200
  size: 0x00008000          # 32 KB Scratch

EMPTY_0:
  address: 0x000fe200
  size: 0x00001e00          # 7.5 KB

prj.conf:

# Enable  MCUboot as Bootloader
CONFIG_BOOTLOADER_MCUBOOT=y

# Enable static partition configuration in pm_static.yml
CONFIG_PARTITION_MANAGER_ENABLED=y
CONFIG_PM_SINGLE_IMAGE=y

# Enable image manager (manage DFU)
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_IMG_MANAGER=y

# Disable multi-image update, only upgrade the application core
CONFIG_NRF53_UPGRADE_NETWORK_CORE=n
CONFIG_UPDATEABLE_IMAGE_NUMBER=1

child_image\mcuboot.conf:

# Use dual-slot DFU mode, and use the scratch area for swaping
CONFIG_MCUBOOT_BOOTLOADER_MODE_SWAP_SCRATCH=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

# Enable signature verification (using ecdsa-p256)
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="C:/02_dataLogger/RTUD/child_image/mcuboot_keys/signing-keys.pem"

# Minimize the size of the bootloader image
CONFIG_WATCHDOG=n
CONFIG_BOOT_BANNER=n

# Disable multi-image update
CONFIG_NRF53_MULTI_IMAGE_UPDATE=n
CONFIG_UPDATEABLE_IMAGE_NUMBER=1
CONFIG_BOOT_UPGRADE_ONLY=y
CONFIG_PCD_APP=n

The signing-keys.pem was generated by imgtool.py keygen -k signing-keys.pem -t ecdsa-p256. In addition, add below in the parent project CMakeLists.txt for image sign:

set(MCUBOOT_SIGNATURE_KEY_FILE "${CMAKE_CURRENT_SOURCE_DIR}/child_image/mcuboot_keys/signing-keys.pem")

In this way, I believe both the parent project and the MCUboot project use the same key. But seems the image verification failed in the MCUboot due to signature verification failed.

my app slot started at address: 0x0000c200 in pm_static.yml, but can not read the correct IMAGE_MAGIC 0x96f3b83d from this address:

Best regards,
Yanpeng Wu

[AHaug]

Hi,

Could you also verify what the result from the zip I sent you was? Were you able to perform non-simultaneous DFU from internal flash with that sample?

Kind regards,
Andreas

[Yanpengwu]

Hi Andreas,

I saw the 6_nrf5340_non_sim.zip is for non-simultaneous DFU of both cores without internal flash, as you described (run on nrf5340_DK?). My current test is on a custom board with a single core (application core) with internal flash only. It seems the scenarios are very different.

Could you give some specific guidance according to the current configuration and log output? I think it was blocked at image signature and verification now, maybe caused by missing something in conf file...

Best regards,
Yanpeng Wu

[AHaug]

Yanpengwu said:

both cores without internal flash,

It is both cores with only internal flash :) I.e non-simultaneous DFU support.

the network core was only used for BLE controller (runs hci_rpmsg child image).

You mention the netcore here? And in the latest comment you don't mention the netcore? I'm a bit confused here, but are you not running any BLE any more and just have a completely empty netcore that is not used at all?

Kind regards,
Andreas

[Yanpengwu]

I run the hci_rpmsg child image on the network core and use it as BLE controller only, so no need to upgrade the network core image after the device deployed. 

All of our applications and BLE host are on the application core, that's why our upgrade strategy is "Dual-slot DFU for application core only". Hopefully I described it clear now:)

[AHaug]

Noted, all clear yes :)

Then it is the non-simultaneous on internal flash you want to do, and that is supported in the exercise I previously mentioned https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-5-fota-over-bluetooth-low-energy/ 

Just be sure that you don't update from an app that can only talk to hci_rpmsg to an app that requires that the interface is hci_ipc, which happened in NCS v2.7.0. From the release notes it's stated "

• Samples and applications that use short-range radio and run on multi-core SoCs were migrated to use the IPC radio firmware as the default image for the network/radio core. Samples previously used for the network/radio core are no longer used in the default builds: HCI IPC, IEEE 802.15.4 over RPMsg, nRF5340: Multiprotocol RPMsg, and Bluetooth: Host for nRF RPC Bluetooth Low Energy."

Kind regards,
Andreas