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!

[Vidar Berg]

Hello,

I'm not sure if I have seen this before. As a start, please run the following commands to compare the bootloader settings content before and after DFU:

$ nrfjprog --readcode flash_content.hex

$ nrfutil settings display flash_content.hex 

Thanks,

Vidar

[Pierre cgwi22]

Hi Vidar, thanks for your answer.

Here are the results for the successful DFU:

Unknown Bootloader DFU settings version: 3922740841

Bootloader DFU Settings:
* File:                     flash_ok.hex
* Family:                   NRF52840
* Start Address:            0x00000000
* CRC:                      0xF6C101EB
* Settings Version:         0x00000002 (2)
* App Version:              0x00000002 (2)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00044184 (278916 bytes)
* Application CRC:          0xAC62AA7C
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x6DCA1671
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

And here for the error state:

Unknown Bootloader DFU settings version: 3922740841

Bootloader DFU Settings:
* File:                     flash_error.hex
* Family:                   NRF52840
* Start Address:            0x00000000
* CRC:                      0x54C8C87F
* Settings Version:         0x00000002 (2)
* App Version:              0x00000000 (0)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00000000 (0 bytes)
* Application CRC:          0x00000000
* Bank0 Bank Code:          0x00000000
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0xACDA1BA2
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

After that, the successive DFU alternate between these two results.

If we compare the settings content in memory, a lot of 0xFFFFFF... (empty parts) are replaced by 0x000000..., the application CRC is lost and the bootloader CRC is different (but data is the same because it is only a DFU for app).

[Pierre cgwi22]

1. Previously we had a problem with the "backup settings" during a DFU from the application (not in BLE) so we have bypassed the settings_backup_valid boolean (set to false) in the file nrf_dfu_settings.c more than one year ago and it worked fine for both application and BLE DFU processes. So it can explain all the zeros because in nrf_dfu_settings_init() there is an erase of the settings if the CRC is wrong. The question is why it is wrong one in two times?

2. The DFU is fully handled by the bootloader in BLE. We can use the application too but for this problem we only use the bootloader to be sure it is not the fault of our app.

3. Yes, the two banks are identical, for valid and failed DFU. Only data in settings are different. So it seems the BLE transfer is good (nRF Connect always indicates a success at the end) but just one in two times something goes wrong in settings --> CRC invalid --> settings erased --> no boot on application even if the data in bank 0 is OK.

[Vidar Berg]

I see. Is it possible to just revert this change for now to see if it makes any difference? Also, please check that both the application and bootloader is compiled with NRF_DFU_SETTINGS_VERSION=2

[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.