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

[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

[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