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.
