• State Verified Answer
  • Replies 8 replies
  • Subscribers 86 subscribers
  • Views 436 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 354928
Options

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

  • 0

    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

  • 0 in reply to Vidar Berg

    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

  • 0 in reply to WoutWG

    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

  • 0 in reply to Vidar Berg

    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.

  • 0 in reply to WoutWG

    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.

     

Related
Terms of service