Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

[WoutWG]

Hi,

I'm working on an application that I recently updated to ncs v3.1.0 (from v2.9.1). For most of the development, I have been working with the nrf54l15 as build target with a custom board, and now I want to transition towards the nrf54l05 since we want to use this in production and we have sufficiently low flash and RAM requirements. Everything builds well when I select the nrf54l05 target, but when I flash the image on our custom board with an nRF54L15 the device doesn't start up correctly. When I debug the application, I see that it breaks at FIH_PANIC() without going to main. We have SB_CONFIG_BOOTLOADER_MCUBOOT=y to use MCUBoot and when I disable this, everything works as expected, also on the nRF54L05. I made sure to copy the nrf54l05_cpuapp.conf from bootloader\mcuboot\boot\zephyr\socs for my custom board, but it also happens when I build for the target nrf54l15dk_nrf54l05_cpuapp.

There are no changes in the devicetree files between the two SOCs, the only difference in Kconfig is that for the nRF54L05 I have the following changes to make it fit with the limited RAM

CONFIG_LOG=n

CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=n

Is there any reason why mcuboot would have issues on nRF54L05 that it doesn't have on the L15? When I try to debug, I also see a popup in vsc to indicate that debugging on the nRF54L05 is not supported yet.

Thanks!

Wout

[WoutWG]

Hi Vidar,

Thank you for the feedback. When I read out the mcuboot_primary address, I get 96F3B83D.

I tried to enable logging and got things to build by increasing CONFIG_PM_PARTITION_SIZE_MCUBOOT slightly. But I still don't see any printing happening. It's hard to connect the RTT viewer before the issue happens. I tried setting a breakpoint at the start of main() in mcuboot to then connect the RTT viewer, but I still don't get output. I stepped through the code and I could see that the issue occurred due to BOOT_SWAP_TYPE(state) == BOOT_SWAP_TYPE_PANIC (see this code bit).

Do you have any pointers why this could happen?

[Vidar Berg]

WoutWG said:

When I read out the mcuboot_primary address, I get 96F3B83D.

Thanks for confirming. This indicates that the signed application image has been programmed at least.

WoutWG said:

I tried to enable logging and got things to build by increasing CONFIG_PM_PARTITION_SIZE_MCUBOOT slightly. But I still don't see any printing happening. It's hard to connect the RTT viewer before the issue happens

The log messages should still be available in the RTT log buffer if you connect the RTT viewer after the bootloader has reached entered the "panic" loop.

Attached is a pm_static.yml and bootloader configuration that has been tested to work on the nrf54l15dk/nrf54l05/cpuapp target. Could you try using the same configuration in your project as a test to see if it works?

pm_static.yml

mcuboot:
  address: 0x0
  region: flash_primary
  size: 0x6000

mcuboot_primary:
  address: 0x6000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0x3a000
  span: *id001
mcuboot_pad:
  address: 0x6000
  region: flash_primary
  size: 0x800
app:
  address: 0x6800
  region: flash_primary
  size: 0x39800
mcuboot_primary_app:
  address: 0x6800
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x39800
  span: *id002

mcuboot_secondary:
  address: 0x40000
  orig_span: &id003
  - mcuboot_secondary_pad
  - mcuboot_secondary_app
  region: flash_primary
  size: 0x3a000
  span: *id003
mcuboot_secondary_pad:
  address: 0x40000
  region: flash_primary
  size: 0x800
mcuboot_secondary_app:
  address: 0x40800
  region: flash_primary
  size: 0x39800

settings_storage:
  address: 0x7a000
  region: flash_primary
  size: 0x3000

MCUBoot configuration

7534.sysbuild.zip

Please also verify that SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU is *not* enabled in your build/zephyr/.config file.

Best regards,

Vidar

[WoutWG]

Thank you Vidar, we managed to get things working. Seems like in our case only 

CONFIG_LTO=y

CONFIG_ISR_TABLES_LOCAL_DECLARATION=y

were necessary. This seems to mostly help to reduce memory size. But since we got the image to build before, just not start up, I'm wondering: Could it be that an image that technically fits in the memory and flash of the MCU doesn't actually work due to some things being out of range?

Best,

Wout