I noticed that the transfer time can be quite long on my devices. Digging into the code, I did a different build where:
- I don't wait with a conservative time
- I insist in dfu_get_status until I get a proper answer instead of giving up
See:
https://github.com/Gregwar/dfu-util/commit/4953f7d4efae738cf00de66caac35357703beb50
This is maybe not the cleanest solution but results in a x4 to x8 flashing time speed bump on my devices
Anonymous
What are your devices? It is the fault of the device if it reports too conservative bwPollTimeout values. It is fundamental to the DFU protocol that the host waits the time it is being told by the device.
My last test was a STM32F446RE
It is true that the poll time seems conservative but if I lower it I get erratic failures
however with my patch its around 5 times faster on this device (and the firmware works without problem)
The ST DfuSe bootloaders are broken in many ways. Some of them even reports a too short bwPollTimeout and then we had to implement ugly workarounds for keeping polling until the device responds again. Relying on this for normal operation is out of question :) DFU is designed to be reliable (very important for embedded user products where bricking is not an option) and lightweight on the device side, and is not optimized for speed.
I guess the inconsistency you are seeing (poll time in average 5 times longer than necessary, but only slightly above the minimum value needed) is because the firmware has little control of how long it takes to erase or write larger flash memory banks - the flash memory controllers grow in complexity and do their work (wear-leveling etc) independently of the microcontroller core - and the firmware just reports one safe value because it cannot predict better.
If ST were to document protocol changes to do this differently, I would look at it, but for now this mechanism is supposed to follow the normal DFU protocol.
I understand that the scope of dfu-util is very huge and the choices might be conservatives one
I will keep my patch as a convenient workaround for developping on my platforms and this ticket can be closed
Last edit: Gregoire Passault 2021-01-10