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

[Matej]

Hello Vidar,

This is the case why I was wondering for protocol documentation and request sequence...

As mentioned I'm implementing dfu flashing on external MCU via UART. Therefore I'm interested in packets description at least a list of min required requests. 

I have checked about following commands; ping, get mtu, and set receipt notification and I think its everything clear...

Now I'm wondering of usage of select, create, write and execute... Could you please provide me a bit info how app/SD is selected, is there option to define also start address?

Thank you for support.

Best regards,

Matej

[Vidar Berg]

Hello Matej,

The content of the update is transparent to the sender. It is the bootloader that know where to place the image in flash based on the update type specified in the transferred init command (the *.dat file). The DFU controller cannot instruct the DFU target to place the image at a specific address.

Best regards,

Vidar

[Matej]

Hello Vidar,

I have managed to transfer image and it boots up if I have flashed only bootloader and softdevice. If I have also application, then always old application boots up.

If I refer to picture above - I'm at the state in the middle column... Is there any command that needs to be sent over to actually switch/replace old application with the new one?

Thank you and best regards,

Matej

[Vidar Berg]

Hello Matej,

The new app should be activated automatically after the last Execute request. I recommend you enable logging over RTT from the target bootloader to see if there are any errors reported during the pre- or post-validation step.

Best regards,

Vidar

[Matej]

Hi Vidar,

I was a bit to fast with reseting and didn't check for execute response; and then i noticed that there is hash error... now I have reworked quite some things... and when I'm sending 64 byte long chunks, now I'm getting an error that allocating buffer has failed.

Any idea? I'm attaching bootloader log:

<info> nrf_dfu_serial_uart: Allocated buffer 20000530
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004EFC0, src=0x2000063C, len=64 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0004EFC0, pending 0
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<error> nrf_dfu_req_handler: Write request too long
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x3
<warning> nrf_dfu_serial: DFU request completed with result: 0x3
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (data)
<debug> nrf_dfu_req_handler: Offset:8192, CRC:0x9C7914AB
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
<debug> nrf_dfu_serial: Sending Response: [0x4, 0x1]
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> app: timer_stop (0x20000028)
<debug> app: timer_activate (0x20000028)
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (data)
<debug> nrf_dfu_req_handler: crc = 0x9C7914AB, offset = 0x2000, max_size = 0x1000
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x6, 0x1]
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0004F000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x0004F000, pending 0
<debug> nrf_dfu_req_handler: Creating object with size: 4096. Offset: 0x00002000, CRC: 0x9C7914AB
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x1, 0x1]
<error> nrf_dfu_serial_uart: Failed to allocate buffer
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004F000, src=0x2000063C, len=64 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0004F000, pending 0
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_serial_uart: Allocated buffer 20001DF0
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004F040, src=0x2000063C, len=129 bytes), queue usage: 1
<error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x2003FF48
<error> nrf_dfu_serial_uart: Failed to allocate buffer
<error> nrf_dfu_serial_uart: Failed to allocate buffer

Thank you in advance!

BR,
Matej

[Vidar Berg]

Hi Matej,

The error below suggests that the bootloader is receiving a packet that is too large:

Matej said:

<error> nrf_dfu_req_handler: Write request too long

There is also this one that indicates that it is receiving packets that are >64 bytes:

Matej said:

<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004F040, src=0x2000063C, len=129 bytes), queue usage: 1

Does your client verify that the reported CRC during DFU is correct?

BR,

Vidar