secure DFU from sdk 12.1 to 15.2 (SD 3.1.0 to 6.1.0) fail with INVALID_OBJECT.

[Eddie]

Hi

We've been using SDK12.1 with softdevice 3.1.0 on a NRF52832 for some time now. Now we want to upgrade our SDK to 15.2 with softdevice 6.1.0. We've converted the application and created a new bootloader using the secure_bootloader pca10040_ble example, changing the dfu_public_key.c with the one we had on the SDK12.

Previously, secure DFU works from SDK12 versions to other SDK12 versions. It also seems to work on SDK15 versions to other SDK15 versions. This with bootloader, softdevice and application together. But when I try to update from SDK12 to SDK15, I receive an error in nRF Connect: INVALID_OBJECT.

I believe the package is created correctly, using

nrfutil pkg generate --application app.hex --application-version x --bootloader boot.hex --bootloader-version y --softdevice s132_nrf52_6.1.0_softdevice.hex --hw-version 2 --sd-req 0x81,0x88,0x8C,0x91,0xAF --sd-id 0xAF --key-file c:/vault/priv.pem output_file.zip

-> yes, we've used a few other softdevice versions before, hence the list in --sd-req

nrfutil version 5.2.0 . Any idea what we are doing wrong?


Part of nRF Connect log:

2019-09-25T11:44:57.366Z DEBUG Destroying DFU transport.
2019-09-25T11:44:57.367Z ERROR DFU failed with error: When writing 'EXECUTE' command to Control Point Characteristic of DFU Target: Operation code 4 (EXECUTE) failed on DFU Target. Result code 5 (INVALID_OBJECT).
2019-09-25T11:44:57.374Z ERROR When writing 'EXECUTE' command to Control Point Characteristic of DFU Target: Operation code 4 (EXECUTE) failed on DFU Target. Result code 5 (INVALID_OBJECT)

[Hung Bui]

Hi Wouter, 

I haven't tried to test the issue yet, but could you clarify --hw-version 2  is correct ? It should match with NRF_DFU_HW_VERSION define in the code (which by default is 52) 

If it actually correct, I would suggest to test with debug version of the bootloader and add the breakpoint (or print log) at where we return NRF_DFU_RES_CODE_INVALID_OBJECT in the bootloader code to see what exactly causing the issue. We have about 5-6 places that we return that error. 

[Eddie]

The hardware version is correct, that is something we adjusted for our own needs.

I think I found the problem though. When I limit the --sd-req parameter to 0x8C,0x91,0xAF, then the upgrade from 12 to 15 seems to work! Is there an issue in nrfutil ? Is there limited storage for these parameters in the created zip? Can you confirm that this might be an issue?

[Hung Bui]

I'm not sure what could be wrong, could you add a breakpoint inside sd_req_check() and check why it fails ? 
As far as I can see in the code, we simply go though all of the sd_req and check if it match the current version.