I'm implementing a DFU controller for the secure DFU bootloader documented here. There is an edge-case I'm hitting that I'd like some clarification on.
As per the documentation, after issuing a select command (06 02) and receiving max_size offset and crc32, our options are either to
a) skip to the execute command if a data object with the correct crc32 is present
b) create a new object if no valid data object was selected
c) continue sending packets from the current offset
If we interrupt the DFU procedure at a point where a whole data object has been transferred, when we re-start the controller and issue a select command (06 02) again, we'll receive an offset that is on an object boundary (offset is divisible by the object size). Our controller will then check the crc32 and if it's a match, skip straight to the execute command (04).
The issue is that sometimes the DFU bootloader will respond accordingly, and in other cases it will simply disconnect and leave the controller in a confused state. My hypothesis is that before we interrupt the DFU procedure, an execute command may or may not been triggered for the last object. Thus, when we reconnect, we can't know if the previous data object has been executed.
Similarly, creating a new object and starting data transfer if the previous object was not executed will leave the DFU target and the controller in mismatched states.
Is there a problem issuing an execute command if a data object has not been created?
Can we somehow know if we should issue an execute command or create a new object if the result from a select command (06 02) returns an offset that is on an object boundary?
