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,

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

[Matej]

Hi Vidar,

Most of things are working now, decryption and flashing etc... but I have one additional question about max app size. Bootloader is configured to use dual bank, but in case that someday application won't fit in memory for dual bank I'm expecting to perform update using a single bank. 

Now I'm wondering if this is done automatically, or is there need to update bootloader in case that application won't fit anymore? I found some posts which are quite old (post1, post2)

Thank you for all your support!

Best regards,

Matej

[Vidar Berg]

Hi Matej,

It's good to hear that things are working now. Regarding your question about dual and single bank updates, the bootloader will automatically perform a single bank update if the app is too large to fit in bank 1 as long as you have not enabled this configuration setting in your bootloader:

Best regards,

Vidar