Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

WoutWG — Thu, 08 Jan 2026 16:04:27 GMT

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

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

Vidar Berg — Tue, 30 Dec 2025 10:32:14 GMT

[quote user="WoutWG"]When I read out the mcuboot_primary address, I get 96F3B83D.[/quote]

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

[quote user="WoutWG"]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[/quote]

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

devzone.nordicsemi.com/.../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

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

WoutWG — Thu, 18 Dec 2025 12:11:40 GMT

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?

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

Vidar Berg — Wed, 17 Dec 2025 07:03:57 GMT

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

[quote user="WoutWG"]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.[/quote]

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.

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

WoutWG — Thu, 11 Dec 2025 08:16:54 GMT

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.

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

Vidar Berg — Mon, 08 Dec 2025 13:52:38 GMT

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

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

WoutWG — Mon, 08 Dec 2025 08:19:32 GMT

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

RE: Issue transitioning to nRF54L05 with MCUboot on ncs3.1.0

Vidar Berg — Fri, 05 Dec 2025 15:58:30 GMT

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