RE: Problem about Serial(UART) DFU

sjheo — Wed, 23 Jun 2021 01:27:41 GMT

Thanks for your comment, Einar.

The DFU test was delayed because I had to deal with other works first. Really sorry about late reply..

As you said, the reason why my DFU process fail is because CRC is different.
The data in the APPLICATION area was written incorrectly.. 😅

Now, I'm done serial(UART) DFU test and I integrated secure bootloader UART and BLE.
Both methods were tested.

But, only the DFU for the application area was tested, and the DFU about softdevice or bootloader area seems to need a little more study.

If I ask a related question later, please kindly answer again.

RE: Problem about Serial(UART) DFU

Einar Thorsrud — Thu, 03 Jun 2021 12:58:50 GMT

Hi Frank,

[quote user=""]1. What does the data I send to the DFU slave DK after creating Object 1 (0x01 0x01 LEN) mean? I don't know the meaning of the data because I followed the nrfutil debug log.[/quote]

Which line in which log do you refer to now? Generally, you can see the format of the commands here. Create object takes two parameters, object type and size.

[quote user=""]2. What is the reason for the above 2) DFU slave UART log result? ( about the response to the CRC and EXECUTE commands.)[/quote]

It looks like the CRC is different. As you have the same .zip file you are testing with I wonder if you are seeing a common issue when doing serial DFU with the DKs, which is that the onboard debugger can corrupt the UART traffic (which passes through it). The workaround then is to disable the pass storage device on the onboard debugger. See Disabling the Mass Storage Device functionality (note that it does not matter if the doc is for Zephyr, this is a generic issue with the onboard debugger on the DK)

[quote user=""]3. The whole test above simply update of the APPLICATION area. How do I update the SOFTDEVICE or BOOTLOADER through serial DFU?[/quote]

The update procedure is exactly the same for SoftDevice or bootloader. This is encoded in the init packet that is sent to the bootloader at the beginning of the upgrade procedure, and the bootloader itself handles the relevant differences without the need for the DFU master to behave any differently for different types of updates.

The bootloader documentation is quite good, though it is a bit slim on the protocol. You will get a good overview for serial DFU from this page.

Einar