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,

The message sequence chart shows the required requests to perform an update. However, this doesn't mean the controller can't send other requests, such as a ping request, before starting the transfer.

Matej said:

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

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

0x1 is the response code and corresponds it to NRF_DFU_RES_CODE_SUCCESS. The MTU size is 0x0083 = 131 bytes.

Best regards,

Vidar

[Matej]

Hello Vidar,

thank you for your reply. Sorry for a bit of delay. Now I',m back and looking forward to understand communication protocol. Now I'm wondering about following request:

it seems that this is create request according to

but according to struct description two arguments of type of uint32_t are expected

but this somehow does not match with captured traffic (flashing blinky example via nrfutil) - or did I missed something?

Thank you for your reply.

Best regards,

Matej

[Vidar Berg]

Hello Matej,

The object_type should probably have been declared as a uint8_t to indicate that it's only 1 byte. As shown in the code snippet below, we extract the object type from the second byte of the request.

 

Best regards,

Vidar