Problem Completing a DFU Update

RE: Problem Completing a DFU Update

Jeremy — Wed, 08 Mar 2023 20:10:05 GMT

I found some more time to dig into my assumptions, and think I'm good to go now. Just a summary post to wrap this up in case somebody finds this in the future.

My problem did have to do with the Bluetooth Mesh flash configuration getting corrupted during the dfu update process. If I add a "stack_config_clear_and_reset()" call to the power-on initialize function my application works being deployed multiple times in a row without issue.

Of course, clearing Mesh configuration every power-up and needing to rejoin the network isn't ideal, but I found another helpful post on the DevZone that addresses passing data between the bootloader and application ( RAM variables exchange between bootloader and application ). I haven't actually implemented this yet, but being able to optionally trigger the configuration wipe only after a firmware update by setting a flag from the bootloader solves my issue completely.

RE: Problem Completing a DFU Update

Jeremy — Wed, 01 Mar 2023 23:17:35 GMT

I'm aware of the different memory layout, I was just clarifying that I adjusted the "blinky" example to include the s140 SoftDevice (adding "debug_additional_load_file", the "S140" preprocessor definition, and changing FLASH_START to 0x2700) so it would be compatible with my application which also uses the s140 bootloader.

I was able to successfully deploy this modified blinky example, which to me confirms that:

1. The combined image is valid (SD + custom application + bootloader)
2. The DFU update process is working ("blinky" started normally after being deployed via BLE DFU)

The question that remains is why my custom application is unable to be deployed in the same way. It works the first time (if I flash a naked bootloader and start with a DFU update), but if I drop back to the bootloader or start with the combined image, "re-deploying" the custom application succeeds but it fails to start.

My custom application uses Bluetooth Mesh which I believe relies on configuration data written to dynamic flash pages, and I think that's where my issue is coming from. I could attempt to clear all stored data and re-provision, but I'd like to only do that after a firmware update and not every time the device is powered on.

My questions are:

1. Does this hypothesis about corrupted Bluetooth Mesh flash configuration data pages make sense?
2. What would be the best way to send a signal to the application from the bootloader to inform it that an update has just taken place and it needs to clear it's data and re-provision?

Thanks,
Jeremy

RE: Problem Completing a DFU Update

tesc — Tue, 28 Feb 2023 16:00:12 GMT

Hi,

It sounds like you found the explanation, yes. The applications that do not require a SoftDevice (SD) and the applications who do, have different memory layout. In nRF5 SDK, for applications with SD, the SD will occupy the beginning of flash with the application on top. For applications without SD, the application is placed where the SD would otherwise be. This definitely could mess up things if DFU-ing from one to the other, yes. Allowing such updates (from SD to no-SD or from no-SD to SD) might require changes to the DFU bootloader. We do however support SD updates where the SD changes in size, although that does void the application so you would then have to use DFU for installing a new application which starts at the end of the new SD.

Regards,
Terje

RE: Problem Completing a DFU Update

Jeremy — Mon, 27 Feb 2023 21:19:15 GMT

I should have thought of this earlier, but I compiled "blinky" modified for the nRF52833 PCA10100 and to include the s140 Soft Device (not needed for blinky, but to keep the overall memory architecture the same), and it is able to deploy without issue.

That is to say I flash the "combined" firmware (sd + custom app + bootloader + bootloader settings), signal my custom app to drop to the bootloader, then deploy the new "blinky" test via BLE DFU. After the DFU update finishes, "blinky" appears to start up and work without issue.

I believe this confirms my suspicion that I don't have a DFU issue, but a first run issue that only comes up when I try to overwrite my custom application with another version of the same BLE Mesh application.