How to detect if usb connection is established

[AlexandrosAA]

Hey. I'm trying to use my H7's usb interface and i've currently set it up as a cdc device.
What i'm trying to implement though is the following. 

The stm is supposed to create a virtual connection with either a python app or a tera term terminal.

Is there a function or a variable that detects if this kind of a connection is established ? For example, the pico equivalent is tud_cdc_connected()

 What i want to build is this

while(!exampleCOnnectionVariable)
{
   HAL_DELAY(500)
}

Meaning that my stm would wait during initialization, until a connection is established and then proceed with the super loop.

[overlaine]

Hello,

From what I remember (as this goes back several years), the serial port was correctly enumerated under Windows, but communication between the devices (the PC and the MCU) did not work.
I tested it again today without the fix, and it now works under Windows.

Most likely this is due to a driver update, if I am to believe this post:
post_link 

[TomZhu]

So we are facing a different problem.

I managed to get the USB hs cdc to work and throughput about 20MB/s, unfortunately I encountered random data lost on windows 10/11 platform. According to SEGGER's Knowledge Base(https://kb.segger.com/CDC) this issue is due to microsoft's horrible new driver development / quality:

DC-ACM issues on Windows 10
Windows 10 comes with a re-designed driver for CDC-ACM. At the time of writing (June 2019) Windows 10 has an issue with large IN CDC transfers. Sometimes packets seems to disappear inside the Windows 10 USB stack.

The only workaround is to read in small chunks. Or to add a delay to the transfers. We have analysed this using a hardware USB analyser and a test program which reads data from the device. The device (USB high-speed) sends out data continuously in 512 bytes packets. Each packet has a unique, consecutive ID. The test application checks that the received packet always has the ID of the previous packet + 1. After a couple dozen packet the error usually appears and a packet ends up missing. When comparing the packets which are seen "on the wire" using the USB analyser with the packets which the Windows 10 program received it can be seen that sometimes packets are missing even though they were clearly successfully received by Windows 10. E.g. on the analyser one can see packets 30, 31, 32, 33 and on Windows 10 one can see 30, 31, 33. It would appear that the method through which data is read from the COM port (Windows API ReadFile, ReadFile overlapped or ReadFileEx) has no effect on the missing packets.

When using the same program on Windows 7 no issues can be seen.

---

So, although the cdc is working it's still useless for me.... I seriously consider to develop a host cdc driver on windows but lack of time.

[overlaine]

Indeed, starting from scratch would take a significant amount of time.

One possible alternative worth considering could be USBTMC. It relies on a different class driver on Windows and may avoid the CDC-ACM limitations and data loss issues observed on Windows 10/11. In addition, it is natively supported on most platforms and commonly used for high-throughput and reliable data transfers in test and measurement equipment.

This might be a more practical approach than developing a custom Windows host CDC driver, especially given the time constraints.

[Pavel A.]

> due to microsoft's horrible new driver development / quality:

IMHO this is very unlikely. Highly used in-box Win11 drivers cannot be that buggy. If someone has solid evidence, please report to Microsoft. (yes there are ways to reach them).

More likely is a firmware issue: violation of some USB specs (bad descriptors, several functions share one endpoint... etc.) or behavior of the firmware.

[TomZhu]

You can find the "solid evidence" provided by SEGGER from the link in my reply:

 .....We have analysed this using a hardware USB analyser and a test program which reads data from the device......When comparing the packets which are seen "on the wire" using the USB analyser with the packets which the Windows 10 program received it can be seen that sometimes packets are missing even though they were clearly successfully received by Windows 10......

---

This is exactly the same issue I encountered, after switch to WINUSB driver problem disappeared (but WINUSB is very hard to use in .NET Framework which I'm using to develop my presentation program).

Those great companies(like MS, INTEL) rising from THE THIRD WAVE are coincidentally fallen, most genius brains of our species turn into different ways(companies). I hope ST can hold their ground longer.

[TomZhu]

Thanks for your suggestion! But I can't switch to USBTMC since a lot modules in my project rely on CDC protocol... Switch all of them into another protocol seems to be impossible...

[TDK]

There is 100% a bug in USB CDC in an updated Windows 11 installation as of today. However, it's not as bad as people often claim and will only bite you when you're transmitting at very high data rates. Entire packets are dropped very rarely, either 64 bytes or 512 bytes (or multiples thereof) depending on USB speed.

I suspect there is an internal buffer that fills up, but the stall flag to not receive any more data on USB has a race condition and lags behind just a tiny bit. For lower speeds, this isn't a problem. When saturating a USB HS bulk endpoint, quite a different story.

There are reports and evidence of this online but unfortunately it's hard to find the actual bug reports and distinguish those from the "bug reports" due to bad coding, as you suggest. Doesn't seem relevant to this thread.

Maybe I'll reproduce this here so I can point to it with evidence.

So yes there is a Windows bug here, but 99% of the time it's not actually the bug affecting the user. All my opinion so take it for what that's worth.