DFU Abort - Invalid Object

[Adam Gordon]

I've been following the instructions on how to test buttonless secure DFU without bonds using the Buttonless DFU Template Application page.

I followed the instructions at the bottom of the page, and loaded the two following precompiled hex files using JLinkExe's command "loadfile":

• examples\dfu\secure_dfu_test_images\ble\nrf52832
  softdevice_bootloader_secure_ble_debug_without_bonds_s132.hex
• examples\dfu\secure_dfu_test_images\ble\nrf52832
  ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex

I then used nRF Connect and performed a DFU using the prepackaged test image:

• examples\dfu\secure_dfu_test_images\ble\nrf52832\softdevice_s132.zip

The DFU started, I could see the progress, and it completed without error.

I then followed the exact same steps, however this time tried to load an image I packaged myself. When I tried to start the DFU, it aborted with the message "Invalid Object."

In order to avoid complications, I packaged the blinky example and did so in the following way:

1. Created a private key: nrfutil keys generate blinky_key.pem
2. Created public key and stored in file: nrfutil keys display --key pk --format code blinky_key.pem --out_file dfu_public_key.c
3. Copied "dfu_public_key.c" to \examples\dfu\dfu_req_handling, replacing the existing file.
4. Prepared the firmware package: nrfutil pkg generate --debug-mode --application nrf52832_xxaa.hex --key-file blinky_key.pem blinky_package.zip

What's causing the invalid package?

Any help on the matter would be greatly appreciated.

[shibshab]

You need to provide a --application-version or --application-version-string which indicates a "larger" version number than the version defined in the standard settings page. Try to add --application-version-string 99.99.99 as an argument when creating the zip.

I'm not sure if this applies when using debug mode though.

[Adam Gordon]

Thanks for the reply. Yeah, debug mode is supposed to cause it to ignore version verification. Either way, I've also tried providing larger version numbers to no success. I have a suspicion that it might have something to do with the signature. I've followed the steps for generating keys, but I'm not quite sure how the public key is getting shared with the device.

[shibshab]

The public key gets shared with the device by including the dfu_public_key.c file you generated in step 2 in the bootloader project. Replace the existing one, and the public key is now stored in the flash of the device.

[bjorn-spockeli]

@adamgordon: Could you try to generate a non-debug package

nrfutil pkg generate --application nrf52832_xxaa.hex --application-version 1 --hw-version 52 --sd-req 0x9D --key-file blinky_key.pem blinky_package.zip

[Adam Gordon]

I had previously tried generating a non-debug package, but I think the issue was with the signature. Apologies for not posting the solution that worked, I was short on time yesterday.

Essentially it might have come down to a couple of things, one minor, one major. The major being that I was trying to use the precompiled examples with my own generated package. This won't work because when I generate my own package, I generate a new private/public key. The precompiled examples have already been compiled using an older public key, so the signature verification will fail. Generating the new keys and THEN compiling the bootloader is what fixed the issue.

Also, I found it odd that I could generate a debug-mode package, but when generating bootloader settings, I needed to provide version information. So I opted not to generate any bootloader settings and compiled the bootloader_secure_ble example which had a pca10040_debug folder. I'm not quite sure of all the details, but it worked.