OTA DFUs no longer working after recreating build configuration

[JakeM]

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?

[Sigurd Hellesvik]

Hi Jake, and welcome to DevZone!

Here you can get answers from our community, we have a lot of skilled people who like to help. In addition Nordic has a team of support engineers, like me, who are assigned tickets and will assist you guys as best we can.

Alright, I like to start by asking some questions to understand the issue better:

When you changed the application now, did you reflash the nRF5340? Or is it just DFU on top of the old app?

Could you check what is inside the .zip file now?

The top memory is the network core I think, and the small bar there should be the network core bootloader (known as b0n). Looks like maybe b0n is missing in your new build. This is a bit strange though, as that should be added automatically. Can you check your build/hci_rpmsg/ folder and see if you find a folder named b0n in here?

Regards,
Sigurd Hellesvik

[JakeM]

Sigurd,

I'm trying to make DFUs that can be applied over apps that have originally been cable programmed.

The zip files for old and new builds both contain only app_update.bin and manifest.json. I don't see any noteworthy differences.

I have found something interesting, however. After cable programming to 0.10 or 0.11, we can DFU successfully to 0.11 or 0.10, just not 0.6–0.9. The same is true for the earlier version range. If cable programmed to 0.6–0.9, DFU to another 0.6–0.9 version works, just not 0.10 or 0.11.

I verified the presence of build\hci_rpmsg\, including a zephyr subdirectory and app.hex file.

The top section shows "Core Name Network" in a tooltip when hovered over. Green bands show "Application", and orange "MBR or Application", so it looks like rather than the bootloader being missing, perhaps the application code is being inadvertently built into the bootloader. Certainly the network core is booting with every version.

Thanks,
Jake

[Sigurd Hellesvik]

JakeM said:

I'm trying to make DFUs that can be applied over apps that have originally been cable programmed.

Which version did you program before trying DFU? 0.9, 0.10 or something else?

JakeM said:

The zip files for old and new builds both contain only app_update.bin and manifest.json. I don't see any noteworthy differences.

If the files had DFU for netcore ready, the zip would also contain a .bin file for the netcore.

Can you check if there is a b0n folder inside build/hci_rpmsg?

[JakeM]

0.6 was the version where I initially added OTA DFU support, by adding CONFIG_BOOTLOADER_MCUBOOT and CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU and a call to smp_bt_register() in main(). We had previously been cable programming exclusively. The hope was for all subsequent versions to be OTA-able over a cable-programmed 0.6 or later.

At some point after making 0.9, I deleted and recreated my build configuration and haven't been able to build OTAs compatible with 0.6–0.9 since; however the builds I've been making with the new build configuration are all compatible with each other.

build/hci_rpmsg does not contain a b0n directory when I make a 0.10–0.11 style build. Unfortunately, I don't have the entire build directory saved for 0.6–0.9, nor do I have ability to recreate them, so I don't know whether they had b0n.

We're trying to understand what broke compatibility to ensure it doesn't happen again.