Direct-XIP MCUboot both images have the same version

Trying to use XIP FOTA updates with nrf connect sdk and nrf52832 to get the extra flash sector (4KB) in space.

Starting with the smp_srv sample, adding bt fragment, and 

CONFIG_BOOT_BUILD_DIRECT_XIP_VARIANT=y to the proj.conf
as well as 

CONFIG_BOOT_DIRECT_XIP_REVERT=y

CONFIG_BOOT_DIRECT_XIP=y

to mcuboot.conf I find that after flashing the fw it just crashes with

*** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting Direct-XIP bootloader
I: Primary slot: version=0.0.1+33
I: Secondary slot: version=0.0.1+33
I: No slot to load for image 0
E: Unable to find bootable image

Is that expected and what's the recommended way to avoid it? 

Is there some guide on how to do direct-XIP updates in practice?

  • I've looked at the shell comands run by the build (using west -v build) and the last one consists of:

    mergehex.py
    -o <path>/smp_svr/build/zephyr/merged.hex 
    --overlap=replace 
    <path>/smp_svr/build/mcuboot/zephyr/zephyr.hex                 // 29952 bytes   That's the bootloader
    <path>/smp_svr/build/zephyr/mcuboot_primary.hex                // 208388 bytes  Primary app (but not signed)
    <path>/smp_svr/build/zephyr/mcuboot_secondary.hex              // 209236 bytes  Secondary app (but signed)
    <path>/smp_svr/build/zephyr/zephyr.hex                         // 208388 bytes  Same file (same CRC) as mcuboot_primary.hex
    <path>/smp_svr/build/zephyr/mcuboot_secondary_app_signed.hex   // 209236 bytes  Same file (same CRC) as mcuboot_secondary.hex
    <path>/smp_svr/build/zephyr/app_signed.hex                     // 209236 bytes  Ever so slightly bigger than mcuboot_primary => Primary app signed
    

    So that doesn't seem right at all.

    I've also added lot's of statements to MCUboot and found that even when I change the logic to select any of the images it doesn't boot because the active_swap_state->magic is set to BOOT_MAGIC_UNSET instead of BOOT_MAGIC_GOOD.

    So then the bootloader deletes the slots :/

  • I think there are two solutions:

    1. Flash a confirmed image (and only one slot)

    So after the build:

    # confirm image
    C:\ncs\toolchains\v2.2.0\opt\bin\python.exe C:/ncs/v2.2.0/bootloader/mcuboot/scripts/imgtool.py sign --key C:/ncs/v2.2.0/bootloader/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 4 --version 0.0.2+33 --pad-header --slot-size 0x35000 --pad --confirm <path>/smp_svr/build/zephyr/mcuboot_primary_app.hex <path>/smp_svr/build/zephyr/app_confirmed.hex
    
    # merge bootloader + confirmed image
    C:\ncs\toolchains\v2.2.0\opt\bin\python.exe C:/ncs/v2.2.0/zephyr/scripts/build/mergehex.py -o <path>/smp_svr/build/zephyr/merged.hex --overlap=replace <path>/smp_svr/build/mcuboot/zephyr/zephyr.hex <path>/smp_svr/build/zephyr/app_confirmed.hex
    
    # flash without rebuild
    west flash --skip-rebuild

    2. Flash a test image and confirm it in application

    # merge bootloader + test image
    C:\ncs\toolchains\v2.2.0\opt\bin\python.exe C:/ncs/v2.2.0/zephyr/scripts/build/mergehex.py -o <path>/smp_svr/build/zephyr/merged.hex --overlap=replace <path>/smp_svr/build/mcuboot/zephyr/zephyr.hex <path>/smp_svr/build/zephyr/app_test_update.hex
    
    # flash without rebuild
    west flash --skip-rebuild
    
    # in application main.c
    boot_write_img_confirmed();

    If you just flash a test image it only works once.

    once you confirm the above, can you ask if this will be fixed upstream? Or show me how I can change it so a Flash / Build action in VSCode results in a flashable merge.hex.

  • I just realised that the "two versions are the same" isn't a problem at all. The way the find_slot_with_highest_version() function in MCUboot's loader.c handles the comparison it just loads the first slot. The problem really lies with the final merge command in NCS.

  •  It seems you have made a lot of progresses. Your findings look right to me. Let me double check them with the bootloader team tomorrow and get back to you. 

  • Hi markuckermann,

    A quick update: I got in touch with the author of the Direct-XIP variant building feature, and they are now checking it.

Related