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

[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