Successive DFU fail one in two cases

[Pierre cgwi22]

Hello,

We are using nRF52840 with SDK 15.3.0, a bootloader and the SoftDevice 6.1.1. An update to the same version of application is allowed in our code.

We discovered a really annoying problem with DFU but the case is difficult to reproduce each time. Most of the time the DFU process in BLE (from NRF Connect app) is performed correctly, but sometimes, after data transfer, the bootloader is not able to launch the application and stays stuck in DFU mode.

From this state, if we start a new DFU with exactly the same application, this time the update works fine and the application is launched.

If we try again to do a DFU (always with the same application), it will fail. And next time, it will work again. So, if a first fail occurs, we can repeat this loop forever, exactly one in two cases : OK > not OK > OK > not OK...

If we compare the content of the memory between these two states, the only difference in at the settings location. Bootloader, SoftDevice and application are exactly the same, but it seems that the settings are wrong one in two times so the bootloader will not validate the application after DFU. From the NRF Connect app, every DFU is shown successful.

We don't understand what can be the reason of the bad settings values one in two times. Have you ever see something like that?

Thanks for your help!

[Pierre cgwi22]

If we remove it, the DFU is OK but the content of the bank 1 is weird. The firsts 12288 bytes of the app data are not in the bank 1, but in bank 0 all data is good and the app is running. I don't understand how it is possible.

Then the second DFU works well too, and this time the bank 0 and bank 1 are both complete.

So without our modification the bootloader is not blocked in DFU mode, but it was not a problem since more than a year.

I have seen something during my tests: if I use the debugger with breakpoints to verify the settings values during DFU, the problem doesn't appear! But if I remove all breakpoints I can see the settings cleared just after the copy of bank 1 in bank 0. Can this issue be based on timing?

[Vidar Berg]

I think I would probably have to reproduce the problem here to understand what is going on. 

Pierre cgwi22 said:

The firsts 12288 bytes of the app data are not in the bank 1, but in bank 0 all data is good and the app is running. I don't understand how it is possible.

Are you sure the bootloader is not just performing a Single-bank update?

[Pierre cgwi22]

Yes it is a dual-bank for sure.

Even if we don't understand why it fails like that, restoring the settings_backup_valid boolean causes the DFU to complete as before. So we will stop the investigation of this problem for the moment, and trying to see what can be the consequences on our app.

We will send a new post here later if we found more information about this problem.