This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Error of INVALID_OBJECT when using nRF Connect (Desktop) after generating DFU zip file with new keys

I'm attempting to create a DFU update using the the ble_app_uart example coupled with the BLE DFU bootloader. It's not unlike this case.

SDK = v16.0.0

nrfutil = v6.0.0a0 (python) and v6.0.0a1 (exe)

nRF Connect for Desktop v3.2.0

Windows 10

S132 v7.0.1 on nRF52832

I had this working about six months ago with SDK v15.3.0, but when I try to re-create a working setup, I get the same error again.

Here are the commands I used:

nrfutil keys generate dfu_private_key.pem

nrfutil keys display --key pk --format code --out_file dfu_public_key.c dfu_private_key.pem

nrfutil pkg generate --application ble_app_uart_pca10040_s132.hex --application-version-string "1.0.0" --hw-version 52 --sd-req 0xCB --key-file C:\u-blox\nRF5_SDK_16.0.0_98a08e2\examples\dfu\dfu_private_key.pem app_v1.zip

I did *not* create a bootloader_settings.hex file yet (it worked without before).

I compiled the secure_bootloader_ble_s132_pca10040 SES project with the new public key, then uploaded it using SES, which also brought along the SoftDevice.

When I attempt to perform the update with nRF Connect, I get the error.

Is a bootloader_settings.hex file needed at this point now?

Any other thoughts?

  • Hi,

    It seems like the byte order of the public key output has gotten reversed in this pre-release. This will cause the bootloader signature validation to fail and the 'INVALID_OBJECT' error being sent to the DFU controller. I will report this as a bug internally. Please try to use nrfutil v.5.2.0 in the meantime.

    Public key from nrfutil v5.2.0 and v6.0.0a1 generated from the same private key:

    /** @brief Public key used to verify DFU images */
    __ALIGN(4) const uint8_t pk[64] =
    {
    0xbd, 0xb1, 0xe3, 0x21, 0x3b, 0x2b, 0xb6, 0x8a, 0x8d, 0xb0, 0x6f, 0x90, 0x27, 0x69, 0xa8, 0x42, 0xac, 0xcf, 0xad, 0x64, 0xfc, 0x65, 0x71, 0x3c, 0x2f, 0x64, 0xbc, 0x92, 0xb5, 0x23, 0x4a, 0x6e,
    0x9a, 0x77, 0xb4, 0x81, 0xc9, 0x3e, 0x3a, 0xaf, 0x7d, 0x22, 0xb6, 0x4b, 0x91, 0xac, 0xe0, 0xbe, 0x5c, 0x10, 0x38, 0x0d, 0x4c, 0x96, 0xde, 0xca, 0x16, 0xd4, 0x69, 0x5a, 0xea, 0xdd, 0xdc, 0x30

    }; 

    /** @brief Public key used to verify DFU images */
    __ALIGN(4) const uint8_t pk[64] =
    {
    0x6e, 0x4a, 0x23, 0xb5, 0x92, 0xbc, 0x64, 0x2f, 0x3c, 0x71, 0x65, 0xfc, 0x64, 0xad, 0xcf, 0xac, 0x42, 0xa8, 0x69, 0x27, 0x90, 0x6f, 0xb0, 0x8d, 0x8a, 0xb6, 0x2b, 0x3b, 0x21, 0xe3, 0xb1, 0xbd,
    0x30, 0xdc, 0xdd, 0xea, 0x5a, 0x69, 0xd4, 0x16, 0xca, 0xde, 0x96, 0x4c, 0x0d, 0x38, 0x10, 0x5c, 0xbe, 0xe0, 0xac, 0x91, 0x4b, 0xb6, 0x22, 0x7d, 0xaf, 0x3a, 0x3e, 0xc9, 0x81, 0xb4, 0x77, 0x9a
    };

    Edit: forgot to add that you only need to generate settings page when you have to manually "mark" an application as valid to the bootloader after programming it through the debug interface.  The settings page is updated automatically by the bootloader when the application is programmed through DFU process.

  • nrfutil v5.2.0 allowed the DFU to complete. Thanks for your help!

    I'll keep an eye on the nrfutil releases.

Related