To preface this question with a bit of context, I am using both a custom board and a custom update tool that I developed to interface directly with the BT SMP service to perform updates. When using the secure bootloader on app B0 along with two updatable mcuboot bootloaders S0, S1 an additional artifact is generated called dfu_mcuboot.zip. This zip contains update files for both S0 and S1.
When I perform an update, both images target the image 0 slot 1 (the application update slot). When confirming either image through SMP and viewing the serial console, only one or the other will actually confirm which depends on which slot is currently the lowest monotonic counter.
For example attempting to upgrade S0 while S0 is the current highest image version, the response is,
*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e *** *** Using Zephyr OS v4.1.99-8ed2f6fccf4f *** Attempting to boot slot 0. Attempting to boot from address 0x8200. I: Trying to get Firmware version I: Verifying signature against key 0. I: Hash: 0xf3...1d I: Firmware signature verified. Firmware version 1 *** Booting My Application v2.1.0-dev-80ee1ad6dfb9 *** *** Using nRF Connect SDK v3.1.0-6c6e5b32496e *** *** Using Zephyr OS v4.1.99-8ed2f6fccf4f *** I: Starting bootloader E: Image in slot is for wrong s0/s1 image E: Cleaned-up secondary slot of image 0 I: Image index: 1, Swap type: none I: Image index: 2, Swap type: none I: Bootloader chainload address offset: 0x20000 I: Image version: v0.0.1 I: Jumping to the first image slot
When trying to upgrade S1 while S0 is the current highest image version, the response is,
*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e *** *** Using Zephyr OS v4.1.99-8ed2f6fccf4f *** Attempting to boot slot 0. Attempting to boot from address 0x8200. I: Trying to get Firmware version I: Verifying signature against key 0. I: Hash: 0xf3...1d I: Firmware signature verified. Firmware version 1 *** Booting My Application v2.1.0-dev-80ee1ad6dfb9 *** *** Using nRF Connect SDK v3.1.0-6c6e5b32496e *** *** Using Zephyr OS v4.1.99-8ed2f6fccf4f *** I: Starting bootloader I: Image index: 1, Swap type: none I: Image index: 2, Swap type: perm I: Image 2 upgrade secondary slot -> primary slot I: Erasing the primary slot I: Image 2 copying the secondary slot to the primary slot: 0xa870 bytes I: Bootloader chainload address offset: 0x20000 I: Image version: v0.0.1 I: Jumping to the first image slot
On subsequent reboots after upgrading, B0 reports Firmware version 2 is active which in this case is now S1 being booted.
The version number is set with,
-Dmcuboot_CONFIG_FW_INFO_FIRMWARE_VERSION=2
I am tying to determine which slot is not currently active, when requesting image info in application through mcumgr with the image list command over SMP I only receive information for,
image 0 slot 0 - default active image
image 0 slot 1 - if an application image was uploaded and pending upgrade
image 1 slot 3 - if a network core image was uploaded and pending upgrade
I cannot get any information on the S0, S1 bootloaders even though they are present in the "all_slots" array here.
I am using this fix I described below to be able to view and confirm network core images, otherwise the array size is mismatched between app and S0/S1
sdk 3.0.2 FLASH_AREA_IMAGE_SECONDARY() returns FLASH_AREA_IMAGE_PRIMARY() id.
Is there a way, in application, to get the S0 S1 version information returned through the SMP update service so I can determine what slot is currently the highest, and thus which slot can be updated?
If not, what is Nordic's expected update procedure for upgrading the S0/S1 images?
Is it expected to just send the mcuboot firmware updates multiple times, rebooting each time for each slot and hoping the updates stick?
