DFU protocol details for a custom DFU controller?

RE: DFU protocol details for a custom DFU controller?

Einar Thorsrud — Tue, 18 Aug 2020 10:35:42 GMT

Hi,

I suspect this is caused by doing post validation before the last chunk of data has been written to flash. There is no part of the DFU protocol that gives you information about that, so I do not see any other solution than waiting a bit so that you are sure that all data is written to flash before doing post validation.

RE: DFU protocol details for a custom DFU controller?

m.reynal — Mon, 17 Aug 2020 10:22:00 GMT

Hello,

I write a controller in cpp to do dfu over ble.

I have the same issue (not a 100% bug) : all crc and offset are ok until the end. But I have a « hash failure » on the last execute command.

I think my controller is sending packets too fast, so last packets are not written yet in flash (queue usage not empty) when execute command is handled by the target. (see target’s logs).

I set PRN to have last packet of each object waiting for response with CRC and offset (see in logs « PRN reached). CRC and Offset are ok, so controller sends execute command… then hash failure

Maybe I’m missing something before the last execute command, something to ‘synchronize’ controller and target (now I have a awfull hack to wait 100ms before sending last execute command?

Thanks.

devzone.nordicsemi.com/.../dfu-ota-_2D00_-hash-failure-_2D00_-target-logs.txt.txt

RE: DFU protocol details for a custom DFU controller?

Einar Thorsrud — Wed, 26 Jun 2019 09:31:27 GMT

Hi,

As you write, the response <60, 04, 0b, 0c> means you have a verification failure (NRF_DFU_EXT_ERROR_VERIFICATION_FAILED). This only happens if validation fails, and since we know the bootloader itself with public key etc is OK (it works if you use another DFU master, and validation can only faile for one of two reasons: either the data is corrupt in some way or the signature is corrupt in some way.

[quote user="scla"] Edit: I checked the CRC's for every data object sent over my controller with the smartphone DFU controller. They are exactly the same![/quote]

Does this apply to all CRC's? And none are missing on the failing case? If so, this indicates that the data is correct, since you have the same CRC values using both DFU masters, even though only one of the DFU masters is working.

[quote user="scla"]Just tried importing and using pc-nrf-dfu-js instead of my own custom controller and have the same issue as in the below link. It looks like the hash in the init packet is not matching with the application file hash.[/quote]

Can you upload the two hashes here? Could it be something as simple as the endianness being swapped?

It could be interesting to see full flash dumps of the device after upgrade in both cases so that we can diff the dumps and easily see what the differences are. You can dump the flash content using for instance "nrfjprog --memrd 0 --n 0x80000 > full_flash.txt" (adjust the size if you have a part with other than 512 kB flash).

RE: DFU protocol details for a custom DFU controller?

scla — Tue, 25 Jun 2019 19:01:08 GMT

Hi Einar, thanks for the reply.

I think I've sorted through most of the issues I was having, which mostly came from not properly understanding data objects. Now I have everything set up like the diagram. Also, I do not set the MTU, but I think I will return to this issue at a later time. Right now I'm sending 230 bytes each iteration which is fast enough for development.

One large issue that I'm running into is creating the last data object. The target gives me a max data object size of 4096 bytes. For the SD + BL init + bin files, everything seems to send correctly until after I send the last data object, CRC command, and execute. CRC checks out fine, but after sending execute I get the response <60, 04, 0b, 0c> which seems to be a validation error. With a smartphone using nRF Connect, I see this same data object being sent with a response of <60, 04, 01> in the logs. Edit: I checked the CRC's for every data object sent over my controller with the smartphone DFU controller. They are exactly the same!

I feel like I'm missing something very simple here for the last data object. Data objects and their sizes seem to be the same as what is in the smartphone logs, however. Any ideas?

Edit:

Just tried importing and using pc-nrf-dfu-js instead of my own custom controller and have the same issue as in the below link. It looks like the hash in the init packet is not matching with the application file hash.

https://github.com/NordicSemiconductor/pc-nrf-dfu-js/issues/44?_pjax=%23js-repo-pjax-container

The DFU package was made with nrfutil and works over a smartphone, so I do not think the package is at fault here. Strange that both my custom controller and pc-nrf-dfu-js fail. Any ideas?

RE: DFU protocol details for a custom DFU controller?

Einar Thorsrud — Mon, 24 Jun 2019 11:46:19 GMT

Hi,

[quote user=""] I am rather confused why this works, since in the sequence diagram it states that I can only send up to 20 bytes at the time.[/quote]

It seems the diagram hs not been updated, and is the same as for older SDK versions, before the bootloader.

[quote user=""]Also, for whatever reason the "Response PRN success" (btw, what does PRN mean?) never occurs.[/quote]

PRN is Packet Receipt Notification. You can see more description in the serial transport layer documentation (though the concept is there regardless of transport):

Before the actual DFU process can start, the DFU controller must set the Packet Receipt Notification (PRN) value and obtain the maximum transmission unit (MTU). In most cases, the PRN can be set to 0 to disable checksums being sent back to the controller during transfers. However, if the transport layer is unreliable, set the PRN to a value other than 0.

[quote user=""]Now I begin the same process as above, but when I send the create command (<01, 02, C8>, where 0xC8 = 200 bytes), I get the response <60, 01, 03>. I cannot seem to find anywhere in the documentation what 03 means. [/quote]

3 is NRF_DFU_RES_CODE_INVALID_PARAMETER. Have you done anything to increase the MTU before this? From the documentation: "If no larger Att MTU size is negotiated with the DFU Service, the expected maximum size of a write is 20 Bytes. "