This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Prevalidation Failure on Init Packet attempting in app DFU. Signature failed (err_code: 0x8542)

In an attempt to do in app DFU I have taken the following resources for inspiration:

nRF5_SDK_17.0.2_d674dde\examples\dfu\secure_bootloader\pca10056_uart_debug

and the DFU_MASTER_UART.ZIP from this link

https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h108sjziaxo3m81rkgr1has5r1d72qtu

Essentially I push the init packet and the application (compiled in as arrays) into the DFU also running in app space. I am hoping that after I transfer both init and app, the DFU code will restart into bootloader, switch and run my new app.

I am trying to send an init packet and an application image to a DFU process I have elevated into application space.

SDK is nrf SDK5 17.02.

Board is 52840DK.

I am seeing a Signature failed (err_code: 0x8542) upon sending the init packet and then sending the execute DFU transport request.

I have tried generating the dfu_zip, wherein I take out the .dat and the .bin, with a couple versions of nrfutil 5.20, 4.00 and 6.10 as some posts on the devzone seems to suggest nrfutil version errors.

The command I am using go generate the dfu zip is as follows.

./nrfutil pkg generate --hw-version 51 --application-version 4 --application nrf52840_xxaa_white.hex --sd-req 0x0100 --key-file ../../../../../../keys/private.key "test_dfu.zip"

I have verified that generating a public key with nrfuti on the private key is repeatable. I have verified that I am compiling the PK variable which matches the private key used to generate the DFU files.

What would you suggest I try next to get this sorted?

All the information from the init file seems to be arriving in the DFU request handler, as I can debug and largely see the contents of the init file in debug structures as they are displayed by nrfutil pkg display test_dfu.zip.

I am seeing the failure in these functions:

nrf_crypto_ecdsa_verify() come back in error with 8542.
nrf_dfu_validation_signature_check()
nrf_dfu_validation_prevalidate()
Parents Reply Children
  • I tried updating the nrfutil --hw-version to 52. I was using nrfutil 6.1.0 to form the dfu zip.

    I verified it updated in debug of the application program.

    p_command.init.hw_version

    is now 52 decimal in the function

    nrf_dfu_validation_prevalidate()

    in nrf_dfu_validation.c

    This suggests to me that transfer of the init packet into the DFU code is working okay and seems well formed.

    I still get the same

    Signature failed (err_code: 0x8542) out of

    nrf_dfu_validation_signature_check()
    of file nrf_dfu_validation_prevalidate.c
    EDIT::
    I found some differences in the way crypto was enabled in the sdk_config.h versus the secure_bootloader example.
    That even includes a different static library included. I'm going to try match the secure_bootloader crypotgraphy configuration and try again.
  • Wow.

    So make SURE, the sdk_config.h cryptography settings match the secure bootloader settings.

    Also make sure to link the same security related static libraries.

    Between these two, I was able to completely verify

    Probably something to do with the ecdsa implemented on either end. Regardless.

    Onto yet another error.

    00> <debug> nrf_dfu_validation: Write address set to 0x00042000
    00> 
    00> <debug> nrf_dfu_settings: Writing settings...
    00> 
    00> <debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
    00> 
    00> <debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 0
    00> 
    00> <error> app: SOFTDEVICE: INVALID MEMORY ACCESS

  • Hello,

    Just FYI, when you press suggest answer, and verify answer, the case no longer appears in the case queue, because it has the status solved. 

    According to your last reply, you still have some errors, right? I'll assume so, until you say the opposite.

    So this is a serial bootloader, right? Have you tested the bootloader against nrfutil to see that it behaves as expected with the generated packet? ("nrfutil dfu serial --help"). 

    From your log, does "Write address set to 0x00042000" refer to the writing of the settings? If so, I find it weird that it is erasing old settings from 0x000FF000. Can you check this, please? If it works when you use nrfutil to perform the DFU, can you compare the logs, and see where it differs?

    Best regards,

    Edvin

Related