MCUboot reports “Image in the primary slot is not valid!” when flashing nRF54L05-compiled image onto nRF54L15 DK (NCS v3.1.0)

Hi,

I am working with NRF54L05 SoC using NRF Connect SDK V3.1.0 and NRF54L15DK for testing.

I am seeing an inconsistent MCUboot validation failure when flashing a firmware build that includes MCUboot. The first time I flash the MCUboot-enabled image, MCUboot prints:

*** Booting MCUboot v2.1.0-dev-2b69d93e75bc ***
*** Using nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, 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: none
E: Image in the primary slot is not valid!

If I then flash an image built without MCUboot, and after that flash the same MCUboot-enabled image again, the MCUboot-enabled image boots/works as expected.

*** Booting MCUboot v2.1.0-dev-2b69d93e75bc ***
*** Using nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, 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: none
E: Image in the primary slot is not valid!

This looks like the first MCUboot-enabled flash is not leaving a valid image in the primary slot (or MCUboot is reading the wrong place), but something about flashing the non-MCUboot image changes flash contents/state so that the MCUboot-enabled image becomes valid on the next flash.

I found the same issue multiple times. Please advise what could cause MCUboot to report the primary slot image as invalid in this setup (nRF54L05 build flashed on nRF54L15 DK) and what checks or configuration details you need to diagnose it.

  • Hello,

    Could you please provide more details about the application you are trying to flash? Have you tried flashing any sample applications from the SDK, and does the same issue occur with those as well? If so, which applications have you tested?

    How are you flashing the image onto the DK? Are you using VS Code? Also, could you please confirm whether you are erasing or recovering the DK before flashing the image?

    I assume you are not performing a DFU. From your description, it sounds like you are flashing an image with MCUboot enabled, which results in the error message you shared. If this is correct, could you please clarify which image from the build folder you are using?

    Kind regards,
    Abhijith

  •  Hi Abhijith,

    Thanks for your reply.

    I was trying to flash my custom application, which is based on the Peripheral LBS sample. In my application, I need DFU support, so I enabled MCUboot.

    I was flashing the application from VS Code, and I encountered another issue when flashing an application with MCUboot disabled. When I tried to flash that application to the DK (where an MCUboot-enabled application was already flashed), the flashing failed with the following error:

    1057782972: Device error: Address 0x00000000 is in a protected RRAMC region (Generic)

    Then I tried flashing from the terminal using west flash --recover, and the flash completed successfully.

    Thank you

    Sachin

  • Hello,

    Could you please try building and running a sample application from the SDK and check whether the same issue occurs? I recommend testing one of the samples from our Academy lessons, please see the same samples here.

    You may also want to review this older DevZone ticket that discusses a similar issue to the one you described. Please check whether FPROTECT is being enabled in the generated build configuration and whether APPROTECT is enabled in your custom application.

    If you’re unable to identify the cause, please share the build folder and I can take a look at the generated configuration. Additionally, sharing a minimal project that reproduces the issue would help narrow it down further.

    Kind regards,
    Abhijith

Related