Potential DFU process bug

[jongor]

I'm currently implementing a DFU "controller" in C on the nRF9160 for performing serial DFU with the nRF52840 and believe I have discovered a bug.

My firmware image was transferred for all but the final block, which was of size less than a code page. This went wrong, and the DFU process was repeated.
In this repeat, the DFU controller attempts to "recover" where it left off by selecting the object and continuing from the position the target responds with - all good so far.

However, if there is now a mismatch in CRCs, the DFU controller wishes to step back a whole object (I can't show my C but the Python equivalent line for nrfutil is here: https://github.com/NordicSemiconductor/pc-nrfutil/blob/afe788d4fd839ed707a1dd870bbd8288e0402949/nordicsemi/dfu/dfu_transport_serial.py#L271)

Now, the next command sent is to create an object, and this is done with max size (a whole object size). But the bootloader is only expecting a less than full object size and rejects the command with code 0x08 as this would go beyond the end of the firmware image it was told about.

I can't quite get my head straight around it but the main problem seems to be the controller wants to step back an object but the target only ever moves forward. There is nothing in the protocol for the controller to specify the offset, it simply hands the target an object. Therefore, the controller shouldn't be modifying its own offset into the part of the image to be sent, no?

[Sigurd]

Hi,

jongor said:

Therefore, the controller shouldn't be modifying its own offset into the part of the image to be sent, no?

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.

[jongor]

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.

[Sigurd]

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.