[BUG] STM32CubeProgrammer USB connection to STM32 BOOTLOADER device fails

[SBone.3]

Hi,

we're having some issues while trying to connect a STM32F030C6 to the Stm32CubeProgrammer via USB, through the embedded STM32 Bootloader.

Using the same working sample of one of our devices, we perform several connection tests on different Windows 10 PCs, all set up with the following configuration:

• STM32CubeProgrammer V. 2.10
• USB plugged directly in the laptop port
• STM32 drivers properly installed

All the PCs were able to properly detect the device in bootloader mode, showing "STM32 BOOTLOADER" in "Device Manager" and some of them were able to properly connect to the device, allowing us to perform DFU operations.

However, on some PCs, the following warning appeared, and no matter what we tried (flag set on "read unprotected", power cycles..etc), we weren't able to connect to the device:

 

Strange thing is, on those problematic PCs, if, instead of using the embedded laptop USB port, we connected the device through an external USB HUB, we were able to connect properly.

This issue is causing us some troubles because some of our customers are stuck and cannot perform the FW update of our devices on the field, and tell them "try to use an USB HUB" is a not viable option.

The issue is sistematic and not related to a specific unit of our device, those problematic PCs always failed, even trying with different units.

The root cause could be in the HW/FW design of our devices, or in the STM32CubeProgrammer toolchain, so:

• In case the issue is on our side, do you have any idea of what could cause this phenomenon based on your experience? (e.g. bad HW design, STM32 Bootloader jump not performed correctly by the FW..)
• In case the issue is inside STM32CubeProgrammer toolchain, Is there a way i can help in order to let you further analyze the issue and provide a fix? maybe providing you some log trace that the STM32CubeProgrammer produces on those problematic PCs. From our analysis, it seems that the issue lies inside the DFU_Driver, since even with a custom DFU library we wrote, we got the same result.

Can you please help? thanks!

[Houda GHABRI]

Hi @SBone.3​ ,

This issue seems to be already raised , to confirm this can you please send me the HW configurations of PCs with which you are having the connection problem (even in private message)?

Houda

[SBone.3]

Hello, here are the specs of one of our problematic PC, we have bunch of them in the company and they all fail to connect:

Operating System: Windows 10 - 64bit

 

All of the above USB ports do not work

Please let me know if you need some other specific details to help you find the issue.

Thanks!

[Pavel A.]

>  Is there a way i can help in order to let you further analyze the issue and provide a fix? maybe providing you some log trace that the STM32CubeProgrammer produces on those problematic PCs.

Yes. Get a trace with a real, hardware USB analyzer.

[Houda GHABRI]

Hi @SBone.3​ ,

I will send you a STM32CubeProgrammer patch by private message, can you please test it and tell me if it solves your problem?

Houda

[SBone.3]

Hi and thank you for your prompt support, unfortunately it did not work, here is the result:I tested the SAME DEVICE on my PC and it gets recognized correctly:

 

Like i said before, i'm pretty confident that the issue lies in the DFU_Drivers:

the reason i'm saying that is because we're using this library:

https://github.com/IntergatedCircuits/LibUsbDfu

to perform DFU operations with a custom C# application that we wrote and we're getting the SAME error of the STM32CubeProgrammer. The only thing common to both program is the DFU_Driver (which we install upon the installation of our C# applicataion by calling "STM32Bootloader.bat" inside the path: STM32CubeProgrammer\Drivers\DFU_Driver)

While you perform further analysis i will try to acquire a USB trace with a USB trace analyzer and share it to you, like Pavel suggested above.

[Houda GHABRI · Accepted solution]

Hi @SBone.3​ ,

I will raise this issue internally to let CubeProgrammer team debug further, I will get back to you with more updates asap.

Internal ticket number: 131169  (PS: This is an internal tracking number and is not accessible or usable by customers).

Houda

[SBone.3]

Hi, any news regarding this topic? we're currently having problems with our customers since when this issue arise we need them to get an USB 3.0 hub to perform DFU operation successfully.

To support you in the analysis i captured the USB trace from a laptop that showed the problem.

Inside the attached DFU USB Trace.zip you can find:

ConnectionOK.csv/ ConnectionOK.sal -> USB trace of successful connection using an external USB 3.0 powered hub connected to the laptop

ConnectionKO.csv/ConnectionKO.sal -> USB trace of unsuccessful connection using laptop integrated USB port

The captures were taken with a Saleae Logic Analyzer Pro: you can decode the traces manually opening the .csv file or download the following SW: https://www.saleae.com/downloads/ and open the .sal file for better readability

Please, let me know if the information i provided is enough for the ST experts to analyze the issue or if they need something more.

Regards,

[JKolj.1]

Thank you @SBone.3​ for raising this issue, and supporting with debugging. We have been struggling with the same thing. I previously thought that the issue was my HW design, but now that I found out about the USB 3.0 hub trick, it consistently works! It was previously erratic with a few of our Lenovo W10 laptops. We are using STM32F765 and STM32F767.

I really hope that ST can take a look and resolve this issue quickly. It is causing a lot of issues with field software updates.

[TCouvrette]

Hi Houda,

Did this ever get resolved?