MCUBOOT only doesn't upgrade with CONFIG_BT_SMP enabled

[gt_jw_eng]

I had previously existing firmware that performed a firmware upgrade using mcuboot and dfu_target. This was done over bluetooth but did not use any existing available bluetooth OTA modules. I had a custom characteristic with write, which would take the written data and feed it to mcuboot through dfu_target. This had no issues and the following config options were enabled for it to work:

CONFIG_ZCBOR=y

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_MCUBOOT_IMG_MANAGER=y

CONFIG_FLASH_MAP_CUSTOM=y

CONFIG_STREAM_FLASH=y

CONFIG_IMG_MANAGER=y

CONFIG_DFU_TARGET=y

CONFIG_DFU_TARGET_MCUBOOT=y

I now want to introduce some features behind CONFIG_BT_SMP to my firmware, so I enabled it, but upon testing, the upgrade process no longer works. I was able to observe through debugging that the application code runs all the way to the point that I would reset the device for the mcuboot upgrade, after calling the following functions:

dfu_target_done(true)
dfu_target_schedule_update(0)

boot_request_upgrade(BOOT_UPGRADE_PERMANENT)

sys_reboot(SYS_REBOOT_WARM)

At this point, usually it would take a short while for mcuboot to upgrade the device, and it would boot into the new firmware, but when CONFIG_BT_SMP is enabled, it boots immediately into the current firmware. No amount of resetting from firmware, or using something like nrfjprog --reset will change this.

However, interestingly, if I go back into the code, and remove CONFIG_BT_SMP, setting it to N, and attempt to flash that new image, the device does not actually boot into this image. Mcuboot seemingly kicks in at some point and loads whatever was in the secondary partition, that I had written to for the dfu_target upgrade earlier. It almost seems like CONFIG_BT_SMP is suppressing mcuboot from loading the image somehow.

[Menon]

Hello,

I will take a look at the shared partition. However, since you’re working with SDK version 2.9.2, the bootloader configurations need to be included inside the sysbuild configuration. You’ll also need to enable CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU to support BLE DFU.

I recommend following this Academy course for adding BLE DFU support , you can find the same sample here.

Kind Regards,

Abhijith

[gt_jw_eng]

HI Abhijith,

Our sysbuild config already contains the necessary SB_CONFIG_BOOTLOADER_MCUBOOT=y. Our goal was not to use the existing BLE DFU fota feature, we wanted the data to come through our custom characteristic, which we would be writing to mcuboot ourselves. This was previously working before enabling CONFIG_BT_SMP=y.

Something we have noticed is that in the call stack here, when debugging mcuboot after requesting an upgrade, on line 546 of swap_move.c, if we have BT_SMP enabled, the conditional will fail which will result in "Not enough free space to run swap upgrade". If we do not have BT_SMP enabled, it will pass.

[gt_jw_eng]

Update, we have resolved the issue. It appears that despite the size of the image indicating it should fit in either partition, mcuboot wants the image size plus the trailer size to be less than the size of the partition minus one page. There was an extreme space limitation that was resolved by reducing the size of mcuboot even further to just 0x8000, and removing some other prj conf enables.