Potential DFU process bug

RE: Potential DFU process bug

Sigurd — Tue, 16 Feb 2021 13:19:42 GMT

Hi,

You can find the documentation for the different DFU requests here: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_dfu_transport.html#lib_dfu_transport_op_descriptions

If we take a look at Create request, then it's stated that it will "Reset the progress since the last Execute command". So if you detect a CRC-error(e.g. with CRC request), and you have not Executed the object, the host could just retry by sending a new Create request. The documentation is not very clear on this point, but if you have Executed the object, and you detect a CRC error after that, it looks like it possible to use the Select request, to trigger the last transferred object of the specified object type to be selected, thus to be made the currently active object. And then you could try to send that object again.

RE: Potential DFU process bug

jongor — Thu, 11 Feb 2021 10:44:58 GMT

I don't feel you've read my question properly. HOST doesn't tell TARGET what offset into the image it is sending. It is always assumed it moves forwards. So when the HOST repeats a block, there is no way for the TARGET to know it is doing that.

RE: Potential DFU process bug

Sigurd — Tue, 09 Feb 2021 11:36:39 GMT

Hi,

[quote userid="75873" url="~/f/nordic-q-a/71370/potential-dfu-process-bug"]Therefore, the controller shouldn't be modifying its own offset into the part of the image to be sent, no?[/quote]

Looking at the python script, then yes, it should modify the offset size based on how many bytes that remains. If less than 'max size' remains, you need to use the amount that remains, and not set it to max.