Menu ▾ ▴

#78 STM32F072 Slow DFU Upload Without USB Hub

none
open
nobody
None
2022-04-19
2019-12-10
Matthew Skolaut
No

I've been using dfu-util on several computers but have found that on a ThinkPad P1 (model 20MD0029US) running Win 10 Pro, the upload speed in incredibely slow (uploads take between 5-20 minutes). The error is "Poll timeout 40 ms". The target is a STM32F072RBT6.

This is mitigated by using any USB hub, and the upload speed is very fast ( <20s upload).

I'm attaching the log in all verboseness levels (cutoff before complete upload due to time constraints).

This issue also appears to be very similar to: https://sourceforge.net/p/dfu-util/tickets/25/ as they are also attempting to program the same device on a lenovo laptop with the same issues (stream of timeouts).

Another note is that this is also occuring with DfuSe from ST, so I assume the microcontroller is misbehaving or the USB chipset is interfering. I'll attempt to test on Ubuntu and provide logs.

3 Attachments
v1_log.txt
v2_log.txt
v3_log.txt

Discussion

  • Matthew Skolaut

    Matthew Skolaut - 2019-12-10

    Adding logs for Ubuntu 19.10, it appears that the problem is not OS related.

     
    v1_ubuntu.txt
    v2_ubuntu.txt
    v3_ubuntu.txt

  • Tormod Volden

    Tormod Volden - 2019-12-10

    Just for the record, "Poll timeout" is not in itself an error, and not an indication of a "timeout" either, it is the naming used in the DFU protocol documents. It is the device bootloader's way to tell the computer/dfu-util that it is busy for a certain time, so we should wait the given time before requesting status again. The device is usually able to know up front how long e.g. a page erase will take, and thus give a sufficient "poll timeout" value so that at our following status request, the operation has finished and the device is ready to move on. The STM32F072RB datasheet specifies a page erase time of 20-40 ms, so the "poll timeout" value of 40 ms is consistent with this.

    From your logs it seems that it keeps repeating the same "busy" answer over and over again. I was first suspecting a libusb or deeper USB stack issue, but since you see the same on a completely different OS, I assume it must be the bootloader or chip itself that is malfunctioning. I don't understand why the hub changes anything, but maybe it is timing critical and the hub introduces a tiny latency. It is the same for USB2 or USB3 hubs, right? Both powered and unpowered hubs?

    Can you please attach the full verbosity log from when using a hub?

    You could experiment editing src/dfuse.c adding a small delay after the special command has been sent, before entering the loop querying for status (line 227 in latest git).

     

    Last edit: Tormod Volden 2019-12-10

  • Matthew Skolaut

    Matthew Skolaut - 2019-12-10

    I tested with a milli_sleep before line 227 and I didn't see any improvement or change with values ranging from 5ms to 1000ms.

    I tested with a few hubs, and they all helped, regardless of 2 or 3, powered or unpowered.

    I'm attaching the log of a successful transfer with the hub attached at full verbosity.

     
    hub_log_win.txt

    • Tormod Volden

      Tormod Volden - 2019-12-10

      Thanks. It looks like even in this case, it takes much more time than needed, there is a second status request so we see two "Poll timeout 40 ms" lines for each erase, and for the programming it returns a poll timeout value of 72 ms also for the SET_ADDRESS request, which shouldn't take any time at all.

       

      • Matthew Skolaut

        Matthew Skolaut - 2019-12-11

        Given that https://sourceforge.net/p/dfu-util/tickets/4/ exists, this may be a quirk in the bootloader. Is there anything else I should try?

         

  • Tormod Volden

    Tormod Volden - 2019-12-11

    You could try, similar to the hack we have for the Black Magic Probe in src/dfuse.c, to just let it continue after 1 or 2 rounds.

     

  • Aurelien BOUIN

    Aurelien BOUIN - 2020-02-07

    Hello,
    I do have the exact same problem but probably on a different host.
    My host is an iMX8MM ARM processor where I have a crosscompiled dfu-util (yocto).
    I do have the same problem : It takes likes 6 minutes to flash an STM32 when I directly connect the STM32 to the iMX8MM.
    But if I connect a switch in between the flash takes 5 seconds
    I do have the same logs than Matthew
    I have also tried to change delays in dfuse.c without success
    If you have any suggestion in how to solve this problem, or help to solve this ...
    Best regards and thank you for your support
    Aurelien BOUIN

     

  • Tormod Volden

    Tormod Volden - 2020-02-07

    Aurelien, is it the same target microcontroller? Did you try my suggested hack to let it continue after 1 or 2 rounds?

     

  • Matthew Skolaut

    Matthew Skolaut - 2020-02-07

    Hi,

    I tried using the hack for the BMP to let it continue but it would never respond non-busy. I tried a wide range of values for timeouts and continues but it never worked.

    I also tried debugging at the signal level and while I could differentiate that there was a timing difference, it was certainly not at the libusb api level to fix.

     

  • Tormod Volden

    Tormod Volden - 2020-02-07

    Aurelien, no I didn't mean those patches, they address a different problem. Anyway as you could see now, Matthew has tried the hack I was referring to, and it did not help.

    Is it only when flashing (downloading)? What about downloading to RAM or reading back (uploading)?
    Do these microcontrollers have any know problems with other USB applications?

     

    • Aurelien BOUIN

      Aurelien BOUIN - 2020-02-28

      Whatever you ask with dfu-util ... it is really slow ... any update or suggestion ?
      I am using USB just for DFU so no idea ...
      Any idea on how we can fake that we use a switch in the USB communication ? (since when we have an USB switch in the middle things get back to normal)

       

  • Anonymous

    Anonymous - 2020-02-21

    Hi, I have tried,and it is because usb 3.0,please use a usb 2.0, then it will fast for F0 serias.

     

  • Tormod Volden

    Tormod Volden - 2020-10-09
    • summary: Slow DFU Upload Without USB Hub --> STM32F072 Slow DFU Upload Without USB Hub
     

  • Anonymous

    Anonymous - 2022-04-19

    Hello,
    I want to share my experiences with a similar device, the STM32F042C6.
    I can confirm with a USB hub (USB 3 or USB 2) the flashing via dfu-util v0.11 is reliable. Using the USB connector of my PC it did not work at all.

    I hope this is some news: with setting the poll timeout explicitly to 1 in the function dfu_get_status():

    int dfu_get_status( struct dfu_if *dif, struct dfu_status *status )
{
[...]
    status->bwPollTimeout = 1; // Explicitly set poll timeout
    return result;
}

    I could achieve that:
    ./src/dfu-util -a 0 -U out.bin -s 0x08000000:0x8000: the upload works always
    ./src/dfu-util -a 0 -D 32k.bin -s 0x08000000: the flash erasing works always and the programming works in 1 out of 20 times

    With this maybe someone can investigate the problem further or share new ideas.

    Greetings
    Jens

     

Anonymous
Anonymous

Add attachments
Cancel