I've previously successfully performed OTA DFUs of our application (basically a heavily customized peripheral_uart), running on hardware substantially similar to the nRF5340 DK. I used the nRF Connect mobile app on both Android and iOS, with the "Test and Confirm" option, to load different firmware images. Those old builds all still work.
We're building against SDK 2.5.3 with toolchain 2.5.3. Thanks to improvements in the 2.5.x SDKs, all I remember having to do to get OTA DFU working was add CONFIG_BOOTLOADER_MCUBOOT, CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU, and CONFIG_REBOOT to the config; and call smp_bt_register() in main().
Unfortunately, after deleting and recreating the build configuration (target nrf5340dk_nrf5340_cpuapp_ns), I can't get OTA DFUs to reliably load anymore. Most of the time it doesn't seem to load anything, and functionally, I can see the application code hasn't been replaced.
The only difference I've observed is that merged_domains.hex looks different loaded in the nRF Connect desktop Programmer tool. I know this isn't the OTA file, but I assume if the .hex is laid out differently in memory, the .bin in the .zip is too, and this is probably what's causing my problems. Notably, the "top" of address space contains only one orange "MBR or Application" region for hex files corresponding to OTA builds that don't work, instead of one orange "MBR or Application" and two green "Application" regions for hex files corresponding to OTA builds that do work. In the image below, 0.5 is from before I added DFU support, 0.6–0.9 have support and work, and both 0.10 and 0.11 built with the new build configuration do not work.
Does anyone know what I might be doing wrong in the build configuration that broke OTA DFUs?
