MCUBoot not a compatible amount of sectors NRF54L15

[Fernando Fontes]

Hi guys,

I'm trying to do FOTA updates on my board and I was able so far to download the image but not able to apply it.

I've followed the academy FOTA over WiFi example but during bootup I see the following warning message:

[0:0:0.8,150] <wrn> mcuboot: Cannot upgrade: not a compatible amount of sectors

[0:0:0.8,156] <dbg> mcuboot: slot0 sectors: 180, slot1 sectors: 163, usable slot0 sectors: 179

What could be the issue here? On the partition manager I see both mcu_primary and mcu_secondary with the same size.

Please check my pm_static.yml:

EMPTY_0:
  address: 0xd800
  end_address: 0xe000
  placement:
    after:
    - mcuboot
  region: flash_primary
  size: 0x800
EMPTY_1:
  address: 0x176000
  end_address: 0x177000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x1000
app:
  address: 0xe800
  end_address: 0xc2000
  region: flash_primary
  size: 0xb3800
bootconf:
  address: 0xffd080
  end_address: 0xffd084
  region: bootconf
  size: 0x4
mcuboot:
  address: 0x0
  end_address: 0xd800
  placement:
    align:
      end: 0x1000
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xd800
mcuboot_pad:
  address: 0xe000
  end_address: 0xe800
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x800
mcuboot_primary:
  address: 0xe000
  end_address: 0xc2000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0xb4000
  span: *id001
mcuboot_primary_app:
  address: 0xe800
  end_address: 0xc2000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xb3800
  span: *id002
mcuboot_secondary:
  address: 0xc2000
  end_address: 0x176000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0xb4000
otp:
  address: 0xffd500
  end_address: 0xffd9fc
  region: otp
  size: 0x4fc
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000
zms_storage:
  address: 0x177000
  end_address: 0x17d000
  placement:
    after:
    - app
    align:
      start: 0x1000
    before:
    - end
  region: flash_primary
  size: 0x6000

Also my sysbuild.conf:

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_PARTITION_MANAGER=y

Any ideias? I'm trying to have a stable version with FOTA so that I can move to the production pilot.

Best regards,

 

Fernando Fontes

[Fernando Fontes]

Ok, I think I've fixed somehow.

I will add here my app.overlay for future reference:

&cpuapp_rram { //! Remove the amount of Flash reserved for the cpuflpr
    reg = < 0x0 DT_SIZE_K(1524) >;
};

&cpuapp_sram { //! Without this the only 188Kb of RAM is available
	reg = <0x20000000 DT_SIZE_K(256)>;
	ranges = <0x0 0x20000000 DT_SIZE_K(256)>;
};

&wdt31 {
	status = "okay";
};

Also the prj.conf for the mcuboot:

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

# NCS boot banner
CONFIG_NCS_APPLICATION_BOOT_BANNER_STRING="MCUboot"

# Disable UART Console and enable the RTT console
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=0
CONFIG_LOG_OVERRIDE_LEVEL=0
CONFIG_LOG_MAX_LEVEL=4
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_MODE_MINIMAL=n
CONFIG_MCUBOOT_LOG_LEVEL_DBG=y
CONFIG_MULTITHREADING=y

CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_HW_STACK_PROTECTION=y
CONFIG_MAIN_STACK_SIZE=10240
CONFIG_BOOT_BOOTSTRAP=n

CONFIG_BOOT_VERSION_CMP_USE_BUILD_NUMBER=y

CONFIG_FLASH=y
CONFIG_FPROTECT=y

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n

CONFIG_SYS_CLOCK_EXISTS=y
CONFIG_CLOCK_CONTROL=y
CONFIG_NRF_GRTC_TIMER=y
CONFIG_NRF_GRTC_START_SYSCOUNTER=y

# Reduce memory consumption
CONFIG_BOOT_BANNER=n
CONFIG_NCS_BOOT_BANNER=n
CONFIG_PRINTK=n

# Use minimal C library instead of the Picolib
# CONFIG_MINIMAL_LIBC=y
CONFIG_PICOLIBC=y

# Activate Link Time Optimization (LTO)
CONFIG_LTO=y
CONFIG_ISR_TABLES_LOCAL_DECLARATION=y

# Improve debugging experience by disabling reset on fatal error
CONFIG_RESET_ON_FATAL_ERROR=n

# Disable GPIO, SPI and SPI NOR
CONFIG_GPIO=n
CONFIG_SPI=n
CONFIG_SPI_NOR=n

# Currently, without tickless kernel, the SYSCOUNTER value after the software
# reset is not set properly and due to that the first system interrupt is not called
# in the proper time - the SYSCOUNTER value is set to the value from before
# reset + 1. Hence, the reboot time increases more and more.
# To avoid it enable tickles kernel for mcuboot.
CONFIG_TICKLESS_KERNEL=y

CONFIG_PM=n

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_IMAGE=n
CONFIG_BOOT_UPGRADE_ONLY=n

# Update MCUboot configuration
CONFIG_MCUBOOT_INDICATION_LED=n
CONFIG_BOOT_MAX_IMG_SECTORS=512
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0xF000

Small portion of the logs for the mcuboot during the swap:

[00:01:24.016,455] <inf> dfu_target_mcuboot: MCUBoot image-0 upgrade scheduled. Reset device to apply
[00:01:24.016,671] <inf> ota_handler: FOTA_DOWNLOAD_EVT_FINISHED
[00:01:24.016,812] <inf> ota_handler: Application FOTA done, rebooting
[00:01:24.022,531] <inf> mcuboot: Starting bootloader
[00:01:24.022,549] <dbg> mcuboot: context_boot_go: context_boot_go
[00:01:24.022,646] <dbg> mcuboot: boot_slots_compatible: Non-optimal sector distribution, slot0 has 179 usable sectors (180 assigned) but slot1 has 180 assigned
[00:01:24.022,687] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:01:24.022,707] <inf> mcuboot: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
[00:01:24.022,710] <inf> mcuboot: Boot source: none
[00:01:24.022,748] <inf> mcuboot: Image index: 0, Swap type: test
[00:01:24.022,754] <dbg> mcuboot: boot_validate_slot: boot_validate_slot: slot 1, expected_swap_type 2
[00:01:24.022,761] <dbg> mcuboot: bootutil_img_validate: bootutil_img_validate: flash area 0xb0c4
[00:01:24.022,765] <dbg> mcuboot: bootutil_img_hash: bootutil_img_hash
[00:01:24.087,497] <dbg> mcuboot: bootutil_tlv_iter_next: bootutil_tlv_iter_next: searching for 65535 (65535 is any) starting at 391192 ending at 391260
--- 9 messages dropped ---
[00:01:24.087,504] <dbg> mcuboot: bootutil_tlv_iter_next: bootutil_tlv_iter_next: TLV 36 found at 391196 (size 64)
[00:01:24.087,510] <dbg> mcuboot: bootutil_img_validate: bootutil_img_validate: EXPECTED_SIG_TLV == 36
[00:01:24.087,519] <dbg> mcuboot: bootutil_verify_sig: bootutil_verify_sig: ED25519 key_id 0
[00:01:24.087,524] <dbg> mcuboot: bootutil_verify: bootutil_verify: ED25519 key_id 0
[00:01:24.087,536] <dbg> ed25519_psa: ED25519_verify: ED25519_verify: PSA implementation
[00:01:24.088,996] <dbg> mcuboot: bootutil_tlv_iter_next: bootutil_tlv_iter_next: searching for 65535 (65535 is any) starting at 391260 ending at 391260
[00:01:24.089,002] <dbg> mcuboot: bootutil_tlv_iter_next: bootutil_tlv_iter_next: TLV 65535 not found
[00:01:24.089,012] <inf> mcuboot: Starting swap using move algorithm.
[00:01:24.089,024] <dbg> mcuboot: swap_scramble_trailer_sectors: swap_scramble_trailer_sectors: fa_id=2
[00:01:24.089,029] <dbg> mcuboot: boot_trailer_scramble_offset: boot_trailer_scramble_offset: flash_area 0xb094, alignment 16
[00:01:24.089,035] <dbg> mcuboot: boot_trailer_scramble_offset: boot_trailer_scramble_offset: final alignment 16, offset 712624
[00:01:24.089,040] <dbg> mcuboot: boot_scramble_region: boot_scramble_region: 0xb094 712624 24656 1
[00:01:24.089,045] <dbg> mcuboot: boot_scramble_region: boot_scramble_region: device without erase, overwriting
[00:01:24.089,052] <dbg> mcuboot: boot_scramble_region: boot_scramble_region: start offset 737264, end offset 712624
[00:01:24.107,318] <dbg> mcuboot: swap_status_init: initializing status; fa_id=2
[00:01:24.107,333] <dbg> mcuboot: boot_write_swap_info: writing swap_info; fa_id=2 off=0xb3fc0 (0xc2fc0), swap_type=0x2 image_num=0x0
[00:01:24.107,339] <dbg> mcuboot: boot_write_trailer: boot_write_trailer: for 0xb094 at 737216, size = 1
[00:01:24.107,409] <dbg> mcuboot: boot_write_swap_size: writing swap_size; fa_id=2 off=0xb3fb0 (0xc2fb0)
[00:01:24.107,416] <dbg> mcuboot: boot_write_trailer: boot_write_trailer: for 0xb094 at 737200, size = 4
[00:01:24.107,484] <dbg> mcuboot: boot_write_magic: boot_write_magic: fa_id=2 off=0xb3ff0 (0xc2ff0)
[00:01:24.107,577] <dbg> mcuboot: swap_scramble_trailer_sectors: swap_scramble_trailer_sectors: fa_id=5
[00:01:24.107,583] <dbg> mcuboot: boot_trailer_scramble_offset: boot_trailer_scramble_offset: flash_area 0xb0c4, alignment 16
[00:01:24.107,590] <dbg> mcuboot: boot_trailer_scramble_offset: boot_trailer_scramble_offset: final alignment 16, offset 712624
[00:01:24.107,597] <dbg> mcuboot: boot_scramble_region: boot_scramble_region: 0xb0c4 712624 24656 1
[00:01:24.107,603] <dbg> mcuboot: boot_scramble_region: boot_scramble_region: device without erase, overwriting
[00:01:24.107,611] <dbg> mcuboot: boot_scramble_region: boot_scramble_region: start offset 737264, end offset 712624
[00:01:24.129,072] <dbg> mcuboot: boot_erase_region: boot_erase_region: flash_area 0xb094, offset 393216, size 4096, backwards == 0
[00:01:24.129,077] <dbg> mcuboot: boot_erase_region: boot_erase_region: device without erase
[00:01:24.144,308] <dbg> mcuboot: boot_write_status: writing swap status; fa_id=2 off=0xadfb0 (0xbcfb0)
[00:01:24.144,374] <dbg> mcuboot: boot_erase_region: boot_erase_region: flash_area 0xb094, offset 389120, size 4096, backwards == 0
[00:01:24.144,379] <dbg> mcuboot: boot_erase_region: boot_erase_region: device without erase
[00:01:24.163,642] <dbg> mcuboot: boot_write_status: writing swap status; fa_id=2 off=0xadfc0 (0xbcfc0)
[00:01:24.163,717] <dbg> mcuboot: boot_erase_region: boot_erase_region: flash_area 0xb094, offset 385024, size 4096, backwards == 0
[00:01:24.163,722] <dbg> mcuboot: boot_erase_region: boot_erase_region: device without erase
[00:01:24.169,739] <dbg> mcuboot: boot_write_status: writing swap status; fa_id=2 off=0xadfd0 (0xbcfd0)
[00:01:24.169,804] <dbg> mcuboot: boot_erase_region: boot_erase_region: flash_area 0xb094, offset 380928, size 4096, backwards == 0
[00:01:24.169,808] <dbg> mcuboot: boot_erase_region: boot_erase_region: device without erase
[00:01:24.179,209] <dbg> mcuboot: boot_write_status: writing swap status; fa_id=2 off=0xadfe0 (0xbcfe0)
[00:01:24.179,304] <dbg> mcuboot: boot_erase_region: boot_erase_region: flash_area 0xb094, offset 376832, size 4096, backwards == 0
[00:01:24.179,309] <dbg> mcuboot: boot_erase_region: boot_erase_region: device without erase

Ok this really get's me happy! I've been struggling with FOTA for days. Apparently, MBEDTLS stoles 70% of the RAM for NRF54L15. Adding the Download while having the TLS for AWS MQTT is not possible, there is not enough RAM for both TLS contexts. 

Only a few questions left though. The app that I'm uploading to AWS is: zephyr/zephyr.signed.bin, and I guess this is being signed with the default cert file. What does CONFIG_BOOT_ENCRYPT_IMAGE=n means then? Isn't the image already encrypted? Or signed is different then encrypted?

What are the requirements for the CONFIG_BOOT_VERSION_CMP_USE_BUILD_NUMBER? I want to prevent downgrades images of being applied.

Best regards,

Fernando Fontes

[Håkon Alseth]

Hi Fernando,

 

Fernando Fontes said:

Ok this really get's me happy! I've been struggling with FOTA for days. Apparently, MBEDTLS stoles 70% of the RAM for NRF54L15. Adding the Download while having the TLS for AWS MQTT is not possible, there is not enough RAM for both TLS contexts. 

I am glad to hear that this is now running!

Yes. mbedtls will use a whole lot of RAM for maintaining the TLS connection, and there are configurations and overlays present here that should give a starting point:

https://github.com/nrfconnect/sdk-nrf/tree/main/samples/net/https_client/boards

 

Fernando Fontes said:

Only a few questions left though. The app that I'm uploading to AWS is: zephyr/zephyr.signed.bin, and I guess this is being signed with the default cert file. What does CONFIG_BOOT_ENCRYPT_IMAGE=n means then? Isn't the image already encrypted? Or signed is different then encrypted?

The image is signed by default, but not encrypted. This is a bit of a wider topic, which you can read more about here:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/ecies_x25519.html

Fernando Fontes said:

What are the requirements for the CONFIG_BOOT_VERSION_CMP_USE_BUILD_NUMBER? I want to prevent downgrades images of being applied.

You must define the version in the application, as described here:

https://docs.nordicsemi.com/bundle/ncs-3.0.2/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_downgrade_protection.html

 

Kind regards,

Håkon