NSIB + upgradable MCUboot: how can an SMP client read the running MCUboot version?

[ddiassword]

Hi,

Setup:

• nRF54L15 with NCS v3.4.1.
• NSIB with MCUboot as an upgradable bootloader (S0/S1), built with sysbuild and no Partition Manager.
• SMP over Bluetooth.

App and MCUboot updates both work. For the app, image list shows slot0: 1.0.0. For MCUboot, the only thing we can query is active_b0_slot, which gives the slot but no version. NSIB only uses the fw_info version, and the semver from SB_CONFIG_SECURE_BOOT_MCUBOOT_VERSION only appears in the update image's header. Copies programmed with west flash (signed_by_b0_mcuboot.hex) don't have that header.

Questions:

1. What is the intended way for a mobile app to read which MCUboot version a device is running? Or should the backend just keep track of which MCUboot package it sent?
2. After an MCUboot update, is checking that active_b0_slot changed the recommended way to confirm it worked?
3. Can production program signed_by_mcuboot_and_b0_mcuboot.hex and its _s1_variant instead of signed_by_b0_*.hex, so the header and semver are there from the start?

Thanks!

[Simon D-M]

Hi,

What is the intended way for a mobile app to read which MCUboot version a device is running? Or should the backend just keep track of which MCUboot package it sent?

I don't know any good way to retrieve the bootloader version directly from another device. It looks like it is possible to get the version from the application though.

So remembering the version with periodic updates from the application looks to be a decent way to do it.

After an MCUboot update, is checking that active_b0_slot changed the recommended way to confirm it worked?

Checking that the slot has changed could indeed be a good confirmation that the updated happened.

Can production program signed_by_mcuboot_and_b0_mcuboot.hex and its _s1_variant instead of signed_by_b0_*.hex, so the header and semver are there from the start?

To be honest here, I've never tried to do it, but I don't really see why it wouldn't be possible.

Let me confirm this internally, and I'll come back to you as soon as I have an answer.

Best regards,

Simon

[ddiassword]

Thanks Simon. For context on point 3, we tried it on the nRF54L15 DK (NCS v3.4.1, sysbuild, no Partition Manager):

- `west flash` programs `signed_by_b0_mcuboot.hex` / `signed_by_b0_mcuboot_s1_variant.hex`. `cmake/sysbuild/image_signing_b0.cmake` has a branch that would point the runner at `signed_by_mcuboot_and_b0_${SYSBUILD_NAME}.hex`. But it's inside `if(CONFIG_BOOTLOADER_MCUBOOT)`, which is never true for the MCUboot image itself (it has `CONFIG_MCUBOOT=y`), so that branch never runs. Is that intended?

- We switched the runner to the `signed_by_mcuboot_and_b0_*` files with a sysbuild hook. NSIB boots both copies, and the version, image hash and key hash TLVs are present from the factory. An MCUboot update over SMP works afterwards, and NSIB still selects by fw_info version.

- Case 119578 reported the same thing for `merged.hex` on NCS v2.7–2.9.

Is there any reason production shouldn't program these files, for example a provisioning or NSIB validation step that expects the image without the header?