nrf54 with mcuboot

[Chris G]

I am adding OTA support using mcuboot with mcumgr on a custom nrf54l15 board with the upgrade (mcuboot_secondary) partition on an external SPI nor flash (not QSPI). I am using the nrfConnect App to perform the DFU. 

1.With the 2.9.1 SDK, I consistently see the image revert if I download it using "Test and Confirm." If I use "Confirm only," the upgrade works correctly and boots my image after the swap. Below are the logs showing the image revert, which occurs without ever launching my application. Note that I don’t see this behavior on a similar application running on the nRF5340. Is this a known issue with the 2.9.x SDK? 

*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***

I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xd000

*** Booting MCUboot v2.1.0-dev-12e5ee106034 ***
*** Using nRF Connect SDK v2.9.1-60d0d6c8d42d ***
*** Using Zephyr OS v3.7.99-ca954a6216c9 ***

I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: revert
I: Starting swap using move algorithm.
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Bootloader chainload address offset: 0xd000
I: Jumping to the first image slot

2. I tested this with the v3.0.0-rc2 SDK, and I no longer see this issue—performing the OTA with "Test and Confirm" works as expected.
However, the MCUboot image is slightly larger than in the previous SDK, so I am unable to fit it into the 0xF000 size I had allocated for the bootloader unless I disable logging.
If I increase this partition size, CONFIG_FPROTECT=y no longer works, since the application then needs to start at 0x10000.
Do you have any suggestions for reducing the size of MCUboot while keeping logs enabled?

Below is the mcuboot.conf I am using: 

CONFIG_LOG_MODE_MINIMAL=y

CONFIG_LOG=y

CONFIG_FLASH=y

CONFIG_SPI_NOR=y

CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_NORDIC_QSPI_NOR=n

CONFIG_MULTITHREADING=y

CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y

CONFIG_BOOT_MAX_IMG_SECTORS=384

CONFIG_PM_PARTITION_SIZE_MCUBOOT=0xF800

CONFIG_FPROTECT=y

# Enable write buffer for faster writes to RRAM

CONFIG_NRF_RRAM_WRITE_BUFFER_SIZE=32

3. In the MCUboot main.c, with CONFIG_FPROTECT enabled, this check tries to protect flash up to the start of the app partition, instead of just the end of the bootloader.
Is that intentional? 

#define PROTECT_SIZE (PM_MCUBOOT_PRIMARY_ADDRESS - PM_MCUBOOT_ADDRESS)  // PM_MCUBOOT_PRIMARY_ADDRESS becomes PM_MCUBOOT_END_ADDRESS. 

If I make that change in main.c to align the protect size to the MCUboot partition size, I’m able to increase the partition size to 0xF800, enable logs, and use FPROTECT in the bootloader. This also removes the need for the mcuboot_primary partition to start at or below 0xF000 when FPROTECT is enabled in the bootloader.

#define PROTECT_SIZE (PM_MCUBOOT_END_ADDRESS - PM_MCUBOOT_ADDRESS)

 

 

[Hieu]

Hello Chris G,

1.With the 2.9.1 SDK, I consistently see the image revert if I download it using "Test and Confirm." If I use "Confirm only," the upgrade works correctly and boots my image after the swap. Below are the logs showing the image revert, which occurs without ever launching my application. Note that I don’t see this behavior on a similar application running on the nRF5340. Is this a known issue with the 2.9.x SDK? 

Not sure if I reproduced your exact observation here, but I tried with "Test and Confirm" and found that:

• Swaps take a lot of time. This is recorded in the Known Issue list, see NCSDK-28567.
• After the new application was successfully booted once, a reset starts Revert swap, but the expected result would be that the image is already confirmed.

Please let me know if you see anything different.

Looking at the nRF Connect Mobile app, my guess is that the app tried to wait for the new application boot to write confirm, but because of the swap time issue, the wait failed and Confirm is never written.

I further tested by connecting to the new application with the Device Manager app, write Confirm, and manually reset the device. The new application is not swapped anymore. This is as expected.

I am having some technical issue with my setup and can't install v3.0.0-rc2. Could you give both version a few tests to see if I was on to something?

Do you have any suggestions for reducing the size of MCUboot while keeping logs enabled?

Chris G said:

Using the v3.0.0-rc2 SDK, I've found that if I don't use the KMU for key storage by setting SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y , the mcuboot image size is reduced by ~20kB which allows me to re-enable FPROTECT and logs in mcuboot.

Can I take it that this works for you now?

3. In the MCUboot main.c, with CONFIG_FPROTECT enabled, this check tries to protect flash up to the start of the app partition, instead of just the end of the bootloader.
Is that intentional? 

#define PROTECT_SIZE (PM_MCUBOOT_PRIMARY_ADDRESS - PM_MCUBOOT_ADDRESS)  // PM_MCUBOOT_PRIMARY_ADDRESS becomes PM_MCUBOOT_END_ADDRESS. 

If I make that change in main.c to align the protect size to the MCUboot partition size, I’m able to increase the partition size to 0xF800, enable logs, and use FPROTECT in the bootloader. This also removes the need for the mcuboot_primary partition to start at or below 0xF000 when FPROTECT is enabled in the bootloader.

#define PROTECT_SIZE (PM_MCUBOOT_END_ADDRESS - PM_MCUBOOT_ADDRESS)

On the nRF54L15, FProtect has a default block size of 0x1000. I am not fully sure if this is something at the hardware level, but as it is, changing MCUboot's main.c like that doesn't give you the desired effect.

Hieu