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

[Vidar Berg]

Hi,

The most common reason for MCUBoot to call FIH_PANIC() is when it does not find a valid bootable image. For example, if the boot signature validation fails. Are you using a KMU slot to store the public key for key validation, and in that case, have you remembered to provision the key?

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

Best regards,

Vidar

[WoutWG]

Hi Vidar,

I'm not (yet) using the KMU to store the public key for key validation, everything on that front is the default out-of-the-box behavior. That's why I find it strange that it works on the nRF54L15 and not on the nRF54L05, unless there is a possibility that even if the build succeeds and doesn't indicate any ROM or RAM issuess there is still a way that there is actually something wrong and 'out-of-bounds'?

Best,

Wout

[Vidar Berg]

Hi Wout,

Please check if the mcuboot image header is written at the beginning of the primary slot address address and that it's not just 0xFF's. This will indicate whether the signed application image got programmed or not. And do you have the possibility to enable logging in the bootloader? 

Best regards,

Vidar

[WoutWG]

Hi Vidar,

What would be the best way to check the mcuboot image header? Should I check the address of the mcuboot_primary or the mcuboot_primary_app? And with which tool? I see nrfjprog provides a --memrd functionality but I'm wondering if there is something similar with nrfutil (I'm not very familiar with it yet). Or is there a way to check the memory report or generated partitions.yml or other files without checking on an actual device?

Bootloader logging is enabled, but I don't see anything being printed. I'm using RTT logger as we don't have a UART available, so not sure if that may have something to do with it.

[Vidar Berg]

Hi,

It's the first words at mcuboot_primary. At the start of mcuboot_primary_app you should expect to see the application's vector table (First word is the initial stack pointer so should be a valid RAM address).

The equivalent to --memrd with nrfutil:

nrfutil device read --address 0x0

WoutWG said:

Bootloader logging is enabled, but I don't see anything being printed. I'm using RTT logger as we don't have a UART available, so not sure if that may have something to do with it.

To support RTT logging, the  bootloader must also have the following configurations CONFIG_MULTITHREADING=y, CONFIG_LOG=y, and CONFIG_LOG_MODE_MINIMAL=n. The problem is that this will lead to a significant size increase which again may require more RRAM to be allocated to the bootloader. Before attempting this, I would try to verify that the device is correctly programmed with the merged.hex that includes the signed application binary with image header at the mcuboot_primary address.

 

[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