Update issue with bootloader chain

Hi everyone, I'm trying to set up a bootloader chain using sysbuild (NSIB → MCUboot → APP) so that MCUboot can act as an upgradable bootloader. I'm working with the nRF54L15 and followed the guides:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild.html
https://docs.nordicsemi.com/bundle/ncs-3.0.1/page/nrf/applications/nrf_desktop/bootloader_dfu.html
With the firmware flashed, the full boot chain works fine. However, when I attempt to update the application using dfu_application.zip via the nRF Connect Device Manager, after the upload and test, the device reboots, but MCUboot can't find a bootable image.

Here's the relevant log output before and after the DFU update:

00> Booting nRF Connect SDK v3.0.1-9eb5615da66b

00> Using Zephyr OS v4.0.99-77f865b8f8d0

00> Fprotect disabled. No protection applied.

00> Attempting to boot slot 0.

00> Attempting to boot from address 0x10800.

00> I: Trying to get Firmware version

00> I: Firmware signature verified.

00> Firmware version 1

00> I: Setting monotonic counter (version: 1, slot: 0)

00> Booting (0x10800).

00> Booting MCUboot v2.1.0-dev-ae1ee57f3906

00> Using nRF Connect SDK v3.0.1-9eb5615da66b

00> Using Zephyr OS v4.0.99-77f865b8f8d0

00> I: Starting Direct-XIP bootloader

00> I: Primary slot: version=0.2.1+0

00> I: Secondary slot: version=0.2.1+0

00> I: Image 1 Primary slot: Image not found

00> I: Secondary slot: version=0.2.1+0

00> I: Image 0 loaded from the primary slot

00> I: Image 1 loaded from the secondary slot

00> I: Bootloader chainload address offset: 0x2b000

00> I: Image version: v0.2.1

00> I: Jumping to the image slot

00> Booting My Application v0.2.1-475bc1ecb46c

00> Using nRF Connect SDK v3.0.1-9eb5615da66b

00> Using Zephyr OS v4.0.99-77f865b8f8d0

(Connection lost)

00> Booting nRF Connect SDK v3.0.1-9eb5615da66b

00> Using Zephyr OS v4.0.99-77f865b8f8d0

00> Fprotect disabled. No protection applied.

00> Attempting to boot slot 0.

00> Attempting to boot from address 0x10800.

00> I: Trying to get Firmware version

00> I: Firmware signature verified.

00> Firmware version 1

00> Booting (0x10800).

00> Booting MCUboot v2.1.0-dev-ae1ee57f3906

00> Using nRF Connect SDK v3.0.1-9eb5615da66b

00> Using Zephyr OS v4.0.99-77f865b8f8d0

00> I: Starting Direct-XIP bootloader

00> I: Primary slot: version=0.2.1+0

00> I: Secondary slot: version=0.2.2+0

00> I: Image 1 Primary slot: Image not found

00> I: Secondary slot: version=0.2.2+0

00> I: No slot to load for image 1

00> E: Unable to find bootable image

Parents
  • Hello,

    Sorry for the delayed response. Andreas will be away for some time, so I’ll be looking into this issue in the meantime.

    Could you share a minimal project that I can run locally to reproduce the issue? I’m asking because I don’t see any specific problem or not sure why it is failing and may need to check internally.

    Also, I believe the smp_svr_mini_boot sample aligns with your use case, is that correct?

    Kind Regards,

    Abhijith

  • Hi,

    Also, I believe the smp_svr_mini_boot sample aligns with your use case, is that correct?

    You're correct that the smp_svr_mini_boot sample aligns in some ways, but my issue specifically relates to migrating to a two-stage bootloader setupnot the single-stage Direct-XIP configuration used in that sample.

    The issue started after enabling the following sysbuild configuration flags:

    SB_CONFIG_SECURE_BOOT_APPCORE=y
    SB_CONFIG_SECURE_BOOT_SIGNING_KEY_FILE="${ZEPHYR_BASE}/../m_band/ota/keys/secure_boot_ed25519_priv_key.pem"
    SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=1
    SB_CONFIG_MCUBOOT_APP_SYNC_UPDATEABLE_IMAGES=y
    


    Also, to help isolate the problem, I tried running the smp_svr_mini_boot sample using SDK 3.1.0-preview4, but encountered the following error:

    /home/tcunha/zp/zephyr/scripts/kconfig/kconfig.py: /home/tcunha/zp/nrf/soc/nordic/nrf71/Kconfig.defconfig:33: error: couldn't parse 'default $(dt_nodelabel_int_prop,grtc,clock-frequency) if NRF_GRTC_TIMER': macro expanded to blank string
    CMake Error at /home/tcunha/zp/zephyr/cmake/modules/kconfig.cmake:396 (message):
      command failed with return code: 1
    


  • Hello,

    Sorry for getting back to you a bit late. It's summer vacation here in Norway, and many are on vacation, which creates some delay in getting back to the issue.

    Tcunha said:
    Also, to help isolate the problem, I tried running the smp_svr_mini_boot sample using SDK 3.1.0-preview4, but encountered the following error:

    It's not recommended to try this version of the SDK, as it is not a stable release. I recommend using version 3.0.2, as it is the latest stable release.

    Kind Regards,

    Abhijith

  • Hi,

    Thanks for the reply, totally understand about the summer holidays.

    I get your point about using a stable SDK, but it looks like the smp_svr_mini_boot sample isn’t available in version 3.0.2. That’s why I tried it with 3.1.0-preview4 to isolate the issue.

    Is there an alternative sample you’d recommend?

  • Hi again, 

    I've picked up this case again since I stumbled across it when working on a similar issue. I believe what is wrong here is the keys you're using to sign the image with. In the original description it looks like MCUboot rejects the new app image in the update because it can not verify it. This is reflected in 

    00> I: No slot to load for image 1
    
    00> E: Unable to find bootable image

    This sample is a bit different from what you want, but I believe you can dissect out what you don't want and add. The readme should also be sufficient w.r.t description of signing both NSIB and MCUBoot with the keys that you need to add at what step etc

    My sample Your project
    NSIB White check mark White check mark
    MCUboot White check mark White check mark
    BLE FOTA White check mark White check mark
    SPI External flash White check mark X
    Direct-XIP X White check mark
    Static partitioning White check mark White check mark
    KMU White check mark White check mark
    Custom private keys White check mark White check mark

    Please let me know if this is helpful. I may spend some time next week attempting to make a version that does not use SPI for external flash and uses direct-xip, but I can't give any guarantees that I have time available for said project since I belive this sample should get you there.

    8_54l15_chain_fota_ext.zip

    Kind regards,
    Andreas

Reply
  • Hi again, 

    I've picked up this case again since I stumbled across it when working on a similar issue. I believe what is wrong here is the keys you're using to sign the image with. In the original description it looks like MCUboot rejects the new app image in the update because it can not verify it. This is reflected in 

    00> I: No slot to load for image 1
    
    00> E: Unable to find bootable image

    This sample is a bit different from what you want, but I believe you can dissect out what you don't want and add. The readme should also be sufficient w.r.t description of signing both NSIB and MCUBoot with the keys that you need to add at what step etc

    My sample Your project
    NSIB White check mark White check mark
    MCUboot White check mark White check mark
    BLE FOTA White check mark White check mark
    SPI External flash White check mark X
    Direct-XIP X White check mark
    Static partitioning White check mark White check mark
    KMU White check mark White check mark
    Custom private keys White check mark White check mark

    Please let me know if this is helpful. I may spend some time next week attempting to make a version that does not use SPI for external flash and uses direct-xip, but I can't give any guarantees that I have time available for said project since I belive this sample should get you there.

    8_54l15_chain_fota_ext.zip

    Kind regards,
    Andreas

Children
  • Hi Andreas,

    Thanks for following up, and sorry for the late reply.
    I don’t think the issue is related to image verification. If that were the case, the logs would explicitly show a verification failure, and I wouldn’t be able to boot into the application after flashing. In my case, I can boot into the app just fine.

    I used your sample as a baseline and then added Direct-XIP and my pm_static setup that i previously provided, but I still ran into the same issue. The app boots fine after the initial flash, and I can see two images available. But after the upload of an updated image, I get the error that no bootable image can be found


    1425.8_54l15_chain_fota_ext.zip

  • Hi,

    I had the time to review your app today. Initially I thought it had to do with your pm_static, but it's due to how the app is built. As I highlighted back in August, the sample I sent you is built to have the MCUboot secondary app on the external flash, whereas direct-xip requires it to be placed on the internal flash. You will have to remove anything that refers to placing the mcuboot secondary application slot on the external flash in sysbuild.conf and sysbuild/mcuboot.conf

    Kind regards,
    Andreas

  • Hi Andreas,

    I believe I have removed all references to placing the mcuboot secondary application slot on external flash, but I’m still seeing the same issue. In my original application, the secondary application was not placed on external flash either.

    Here are the logs and the sample I used.

    *** Booting MCUboot v2.1.0-dev-ae1ee57f3906 ***
    *** Using nRF Connect SDK v3.0.1-9eb5615da66b ***
    *** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
    I: Starting Direct-XIP bootloader
    I: Primary   slot: version=4.9.0+0
    I: Secondary slot: version=4.9.0+0
    I: Image 1 Primary slot: Image not found
    I: Secondary slot: version=4.9.0+0
    I: Image 0 loaded from the primary slot
    I: Image 1 loaded from the secondary slot
    I: Bootloader chainload address offset: 0x4a000
    I: Image version: v4.9.0
    I: Jumping to the image slot
    *** Booting My Application v4.9.0-7de04188b692 ***
    *** Using nRF Connect SDK v3.0.1-9eb5615da66b ***
    *** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
    Starting 7_54L15_fota_ext sample
    I: 26 Sectors of 4096 bytes
    I: alloc wra: 0, f70
    I: data wra: 0, 10
    I: SoftDevice Controller build revision: 
    I: 89 9a 50 8a 95 01 9c 58 |..P....X
    I: fc 39 d2 c1 10 04 ee 02 |.9......
    I: 64 ce 25 be             |d.%.    
    I: HW Platform: Nordic Semiconductor (0x0002)
    I: HW Variant: nRF54Lx (0x0005)
    I: Firmware: Standard Bluetooth controInside main loop after encrypted dfu
    Connected
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    Inside main loop after encrypted dfu
    *** Booting MCUboot v2.1.0-dev-ae1ee57f3906 ***
    *** Using nRF Connect SDK v3.0.1-9eb5615da66b ***
    *** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
    I: Starting Direct-XIP bootloader
    I: Primary   slot: version=4.9.0+0
    I: Secondary slot: version=5.9.0+0
    I: Image 1 Primary slot: Image not found
    I: Secondary slot: version=5.9.0+0
    I: No slot to load for image 1
    E: Unable to find bootable image

    8_54l15_chain_fota_no_ext.zip

  • Hi again,

    I revisited this case and I see that I may have misunderstood the status of this ticket a while back. Apologies for that.. Did you ever succeed in configuring direct XIP for either the sample you've been working on or for the Peripheral LBS sample as described here? https://docs.nordicsemi.com/bundle/ncs-3.0.1/page/nrf/app_dev/device_guides/nrf54l/fota_update.html#build_configuration_additions_for_mcuboot_in_the_direct-xip_mod

    Kind regards,
    Andreas

Related