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

[Bycman]

We are upgrading our product from SDK15 to SDK16 using DFU over USB. When we perform a DFU update (BL, SD, and App) form SDK15 to SDK16, it works fine. Then if we perform a DFU update back to SDK15 it works fine (BL, SD, App). Then if we try to go back to SDK16, it is stuck in DFU mode and we have to perform a second update to get to SDK16.

While this may not seem like a useful scenario, it really is since if bugs our found in later firmware and end users want to revert to previous versions. They will be locked at older versions at that point (unless we force updates to happen twice, but we would like to understand the root of the problem).

We have modified the bootloader code to allow downgrade of BL, SD, and Apps. We can also update from an SDK15 to SDK15 release fine and from an SDK16 to SDK16 just fine. And SDK15 to SDK16 works fine the first time. But any other time after that, going from SDK15 to SDK16 fails.

I have dumped the flash after both the first (success) and second (failed) attempts, and they show a 6 byte difference only past the bootloader addresses (0xFE25C and 0XFF25C, bootloader settings?).

Here is the command we are using to generate the update packages:

SDK15

C:\Python27\Scripts\nrfutil pkg generate --hw-version 52 --application-version 1 --application-version-string 1.4.5 --application ..\Output\Release\Exe\FW_App.hex --bootloader-version 7 --bootloader ..\Output\Release\Exe\FW_Boot.hex --sd-req 0x00 --sd-id 0xA9 --softdevice ..\nordicsdk-15.0\components\softdevice\s140\hex\s140_nrf52_6.0.0_softdevice.hex --key-file ..\priv.pem ..\Output\packages\FW\bt_sd_app_dfu_package.zip

SDK16

nrfutil pkg generate --hw-version 52 --application-version 1 --application-version-string 2.4.248 --application ..\Output\Release\Exe\FW_App.hex --bootloader-version 9 --bootloader ..\Output\Release\Exe\FW_Boot.hex --sd-req 0x00 --sd-id 0xCA --softdevice ..\nordicsdk-16.0\components\softdevice\s140\hex\s140_nrf52_7.0.1_softdevice.hex --key-file ..\priv.pem ..\Output\packages\FW\bt_sd_app_dfu_package.zip

I have tried using bootloader with settings instead of just a standalone bootloader, but nrfutil errors out when I include the settings.

[Hung Bui]

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. 

[Bycman]

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?

[Hung Bui]

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.