Bootloader DFU transport - transfer of init packet

[Matej]

Hi,

I'm implementing flashing modul, which will be running on external mcu. Therefore for the very 1st step, I have captured traffic while performing dfu on PCA10040 via nrf util from PC. Now I'm wondering of the meaning of transferred bytes, since it's not matching to decription in sdk.

First captured packet is: 0x09 0x01 0xc0; according to dfu transport shall be 0x02 0x00 0x01..

After response 0x60 0x09 0x01 0x01 0xc0, similar packet is sent 0x02 0x00 0x00 0xc0 and finally get response set prn success 0x60 0x02 0x01

Then Get MTU is following... and then I get a bit different response 0x60, 0x07, 0x01, 0x83, 0x00, 0xc0 --->how many bytes are use to represent MTU?

Now I'm wondering if there is any document/manual with detailed description of transfered bytes (somehow I didn't find it), or is there any existing code/library for performing dfu, that could be used for implementing flashing procedure on external mcu via uart.

Thank you in advance.

Best regards,

Matej

[Vidar Berg]

Hi Matej,

Did the log indicate if the post-validation step failed or passed on your first attempt (the image hash is validated in this step)? 

Best regards,

Vidar

[Matej]

On first attempt, there is nothing about validation... right after crc response has jumped to 0xa80 and after that boots up like nothing happend - except that app is missing... in next try everything looks like expected.

BR,

Matej

[Vidar Berg]

I would recommend you try to place a breakpoint at this line in your bootloader:

to confirm if the postvalidation is being run on the first round. This is where the hash of the receivied image is being verified. The image will not be marked as ready for activation if the validation fails.

Best regards,

Vidar

[Matej]

Hi Vidar,

Thank you for inputs, will check later in afternoon...

In between I have also tried with required signing of app and unfortunately I hit to another issue with prevalidation.

Init packet is ok transferred - content match to dat file, crc response also match, but on execute command I receive response 5, since ecdsa_verify function returns 0 - meaning signature is not valid (0x8542). I'm using micro ECC library.

I have noticed that there is quite some posts around generating keys with some versions of nrfutil had some problems around byte order and there are also some variations how crypto library is compiled.

devzone.nordicsemi.com/.../key-pair-generation-with-edcsa-secp256k1 

devzone.nordicsemi.com/.../prevalidation-failure-on-init-packet-attempting-in-app-dfu-signature-failed-err_code-0x8542 

Therefore I kindly ask, if you can provide generated key pair (private+public) for debugging purposes only and prebuild micro_ecc library for nrf52840, to isolate at least this part.

Thank you in advance.

Beste regards,

Matej

[Vidar Berg]

Hi Matej,

Sorry for the delay. I've been out of the office for a few days. Have you made any progress on this in the meantime. The byte ordering/endianess should be correct when using the default configurations. You can test your uecc library with the BLE bootloader projects to verify if it is working or not. 

Did you build the bootloader with your generated public key, and did you use the corresponding private key when signing the FW update?

Best regards,

Vidar