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]

Hello Matej,

The DFU controller is starts by sending a ping request in your case.

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?

The MTU is represented with 2 bytes (uint16_t)

Best regards,

Vidar

[Matej]

Vidar, thank you, for your response.

I see, there are listed different OpCodes, for several requests. Is there any list of requests order (collected at one place), that needs to be sent for successful update? 

What is the timeout between request, before dfu is aborted? 

On "Get MTU" request 0x07, 0xC0, i get response:

• 0x60 (indicating response)
• 0x07 (get mtu rsp)
• 0x01, 0x83 (size)
• 0x00 status?
• 0xc0 (slip end)

while on ping req i get response i get 

• 0x60 (indicating response)
• 0x09 (ping request)
• 0x01 ping id
• 0x01 status?
• 0xc0 (slip end)

Now i'm wondering about bold status bytes? are those really status or something else? where can i find byte-to-byte overview?

Thank you in advance for additional support

Best 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

[Matej]

Hi Vidar,

No problem at all... I have switched from uecc to cc310_bl and used prebuild library from sdk and set bootloader settings to version 2 and now signature and verification works as expected...

Unfortunately I have a new problem, with aes-ctr encryption... Since aes-ctr is supported within cc310, but once I enable both of them cc310 and cc310_bl there is problem with mutex...

Do you have any suggestion how to proceed with this? Since cc310_bl is working without problem with signature and verification, most probably I will implement aes-ctr independent of sdk. 

BR,

Matej

[Vidar Berg]

Hi Matej,

I thought you were using the nRF52832. The bootloader projects for the nRF52840 defaults to using the cc310 to take advantage of the HW accelerated crypto services. Are you attempting to use AES in your application, or in the bootloader? 

Best regards,

Vidar

[Matej]

Hi Vidar,

I made some initial dfu packets capture on pca10040, but for project i'm using nRF52840... I'm planning to use AES in bootloader. The scenario is following in post build step application will be encrypted since it's stored in external flash. Then main MCU reads encrypted image and send it to nRF bootloader which will decrypt image.

By default NRF_CRYPTO_BACKEND_CC310_BL_ENABLED is enabled and once I'm trying to enable also NRF_CRYPTO_BACKEND_CC310_ENABLED there is problem with mutex.

Most probably I will implement aes-ctr independent of sdk since the most of things is now working with NRF_CRYPTO_BACKEND_CC310_BL_ENABLED. I have already spent quite some time around this and I'm not sure if there will be so much benefit for switching to CC310 and struggling with new issues, since update will be performed only few times in lifetime of product.

Best regards,

Matej

[Vidar Berg]

Hi Matej,

I see. The bootloader is configured to run with the 'NRF_CRYPTO_BACKEND_CC310_BL_ENABLED' variant of the cc310 runtime library. This is a stripped down version compared to the cc310 library used in our application examples and only includes the features necessary for DFU. The full version of the library is located in /external/nrf_cc310/lib.

Best regards,

Vidar