Successive DFU fail one in two cases

RE: Successive DFU fail one in two cases

Pierre cgwi22 — Mon, 03 Oct 2022 07:31:48 GMT

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.

RE: Successive DFU fail one in two cases

Vidar Berg — Mon, 03 Oct 2022 06:46:38 GMT

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

[quote user="Pierre cgwi22"]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.[/quote]

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

RE: Successive DFU fail one in two cases

Pierre cgwi22 — Tue, 27 Sep 2022 15:22:06 GMT

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?

RE: Successive DFU fail one in two cases

Vidar Berg — Tue, 27 Sep 2022 09:04:57 GMT

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

RE: Successive DFU fail one in two cases

Pierre cgwi22 — Tue, 27 Sep 2022 08:38:44 GMT

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.

RE: Successive DFU fail one in two cases

Vidar Berg — Tue, 27 Sep 2022 07:28:50 GMT

It's strange that most of the elements from the settings struct are set to zero in the failing case. Some more follow up questions:

1. Have you made any modifications to the bootloader that might be relevant?

2. Is the DFU transfer handled by the application or bootloader?

3. If the update is dual-banked, does the app in bank 1 match the one in bank 0?

RE: Successive DFU fail one in two cases

Pierre cgwi22 — Mon, 26 Sep 2022 15:06:35 GMT

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

RE: Successive DFU fail one in two cases

Vidar Berg — Mon, 26 Sep 2022 13:29:28 GMT

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