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

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.