DFU Update fails second time updating from SDK15 to SDK16 firmware (BL, SD, App)

RE: DFU Update fails second time updating from SDK15 to SDK16 firmware (BL, SD, App)

Bycman — Tue, 28 Jul 2020 23:11:04 GMT

OK, I am erasing the settings page when I go backward. now it works.

RE: DFU Update fails second time updating from SDK15 to SDK16 firmware (BL, SD, App)

Hung Bui — Thu, 16 Jul 2020 13:30:53 GMT

Hi Bycman,
In our current implementation we don't have a feature to clean the bootloader setting. You may need to implement that in the bootloader code. Maybe to clear the bootloader setting when there is a SD+BL update (but not when only a BL update).

I would suggest to test DFU with the debug version of the bootloaders. It's easier to debug with these versions.

RE: DFU Update fails second time updating from SDK15 to SDK16 firmware (BL, SD, App)

Bycman — Tue, 14 Jul 2020 18:05:16 GMT

Yes, I used the same exact zip file on first and second attempt to go to SDK16 package. When I say stuck in DFU mode, it seems like it is running the SDK16 bootloader. I say that because I dumped the entire flash after first SDK16 update and second SDK16 update and they are the same with the exception of those few bytes. I also tried to attached a J-Link Debugger after the failure of the second SDK16 attempt and I was able to step through with my SDK16 Bootloader project, but not the SDK15 Bootloader project.

That sounds like a great idea to erase the bootloader settings and clear the CRC validation and validation type. I assume to do this I need to modify the Bootloader source code. Or is there a way to accomplish this via the nrfutil package creation utility that would cause the Bootloader to erase that region?

RE: DFU Update fails second time updating from SDK15 to SDK16 firmware (BL, SD, App)

Hung Bui — Tue, 14 Jul 2020 09:36:13 GMT

Hi Bycman,

I assume you were testing using SDK v15.0 and SDK v16.0 based on the paths you provided.

There is a fundamental change in SDK v15.3 and continued in newer version of the SDK is the bootloader validation. You can read more about that here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/lib_secure_boot.html?cp=7_5_0_3_5_0_8

You can see the difference between SDK v15 and SDK v16 in the code by having a look at nrf_dfu_settings_t struct in nrf_dfu_types.h

The 6 bytes difference you located actually pointed to the boot_validation_crc.

I'm not 100% sure what exactly happened but my hypothesis is that on the first DFU update to SDK v16 the bootloader setting at address 0xFE25C was blank and the bootloader in SDK v16 (designed to be backward compatible) will detect that it's been updated from older version. It will continue and update the CRC to match with its CRC.
On the second update, for some reason the CRC value is not the same any more and it's also not blank (0xFFFFFFFF) , then we will have a CRC fail.

When you update DFU to SDK v16 on the 2nd time, did you use the exact same .zip file as the first time or it's a different one ?
When you mentioned that "Then if we try to go back to SDK16, it is stuck in DFU mode " it's stuck in the bootloader of version 15 or it's the bootloader of version 16 ?

My suggestion is that when you move from SDK v16 back down to SDK15 , the bootloader setting page has to be erased completely. And the CRC validation and validation type in the bootloader setting should be cleaned.