STM32F4 Usb fails to work only when in debug mode

[MB.2]

I am working on a basic USB FS HID device on an STM32F411 Discovery Board, the USB code is the only code on the board. When I run the code from the STM32CubeIDE, the device fails to enumerate and Windows says "Device Not Recognized". I have no breakpoints, delays or anything else set in the program that would cause a pause. When I plug the device in outside of debug mode, the device works as expected, and I can receive data fine in the desktop application.

The device ALWAYs works as expected outside of the IDE even in Windows and Linux on different computers. I changed all of my debug settings for debug connections (connect under reset, etc), but it still has the same issue. I'd like to get this to work as the SWO output is useful to debug the OUT packets the device receives.

The only way I can seem to get the device to work properly in Windows is if I change the VID or PID, then it enumerates fine. But if I run it again, it seems to fail, so I'm wondering if this is related to something Windows is doing with the driver or device manager settings.

I've tried resetting the USB control registers, I've tried resetting the PORTA to its init values explicity, and I've tried holding PA12 (USB DP) to low as suggested here:
https://community.st.com/t5/stm32-mcus-products/usb-cdc-dont-work-in-debug/td-p/464797

Has anyone encountered this issue before? It's really frustrating because it's making it impossible to debug my device without constantly changing the VID or PID.

[MB.2]

Additionally, I've increased the stack and heap size but it seems to make no difference.

[Pavel A.]

Windows 10/11 (maybe 8+) caches some descriptor info in registry, to speed up enumeration. This may be related to your workaround with changing the VID/PID. But I don't understand how this can fail enumeration. This very likely can change timing. I don't believe that Windows does something non-standard, for example, reads descriptors in less than 100 ms after reset. They must be very accurate with this. But debugger can cause more than 100 ms delay. 

OTOH, Linux is more relaxed and closer to real life. If you can debug against a Linux host - do this and avoid wasting your time with Windows. Return to Windows later.

Check (with a scope) that the device does not indicate its presence on USB immediately after power up. This should not occur before your software is running and ready for enumeration. Otherwise, small delay caused by debugger can be fatal.

 

[MB.2]

Yeah, I figured Windows may cache it or do something weird. Unfortunately, I cannot debug on a Linux machine as the desktop application is a Windows application. 

Unfortunately, I also run into an issue where sometimes when I try to connect to the running target, the device ends up restarting and then failing to enumerate. I'm not resetting it so I don't know why this is happening, these tools are so frustrating to use. 

[MB.2]

I tried it out on a Windows 10 laptop and it has no issue. So it may be either: the USB controller HW or driver in this laptop, or it is Windows 11. This is pretty weird. 

[waclawek.jan]

Is the same binary running in both the working ("no IDE") and non-working ("with IDE") cases? I.e. do you switch between "Debug" and "Release" profiles when going to the "no IDE" case, or not?

What's your USB topology? Do you use a hub, or just two cables? When the reset happened, what was the USB topology, were you attempting to connect the debugger to one computer and the target to other (I am aiming at different ground levels)?

JW

[MB.2]

The binary is the same on the device (debug binary). 

I plug directly into my laptop's USB ports. The device was plugged into the same laptop I am debugging with.

Additionally, if I plug USER USB connection into a Linux PC while debugging, it connects and works fine. I did the same with a Windows 10 PC, it works fine. 

In fact, on a different laptop with Windows 10, I can run the debugger and code on the development board directly from the IDE without any issues. It enumerates fine.

But I noticed that in Windows 10, devices tend to enumerate a bit slower (mice, keyboards). So it may be how the two operating systems enumerate devices. 

[Pavel A.]

>  the device ends up restarting and then failing to enumerate. I'm not resetting it so I don't know why this is happening

This can be exactly the result of delays caused by debugger. If the host sees that the device does not respond for (IIRC) about 100 ms, it can reset the device and re-enumerate. You'll need a real hardware USB analyzer to debug this.

[MB.2]

Unfortunately, I don't have access to a hardware USB analyzer and they tend to be expensive. On a different laptop with Windows 10, I can run the debugger and code on the development board directly from the IDE. It enumerates without any issues.

It seems that in Windows 10, devices tend to enumerate a bit slower (mice, keyboards). So it may be some difference in how the OS wants to enumerate USB devices or some sort of caching it does for enumerating faster.