2

The Microsoft article "USB serial driver (Usbser.sys)" tells that:

If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the Device Descriptor.

If I program a STM32 MCU with a CDC example with 02 class code (CDC) and 02 subclass code (ACM), the usbser.sys loads. And this makeshift USB-UART bridge detected as "Ports (COM and LPT)/COM5". If I use some USB-UART bridge IC (like FT232), commonly it's class is "Vendor specific" and they need a vendors driver. If the vendor driver has install this devices are also detected as "Ports (COM and LPT)/COMx"

The Cypress USB-UART bridge CY7C65213 has 02/02 class/subclass in the descriptor. But without the Cypress driver, this IC detected as "Other devices/Virtual Serial Port Device 00".

Actually, I can install the Cypress driver, this IC will detected as COMx and my soft will work well.

But I want to understand why the usbser.sys driver is not loading with this device? How can the Windows understand that some USB CDC-ACM devices need the usbser.sys and the other don't need this driver? Is the difference in the descriptor or somwehere else? What instruments shall I use to spot the difference and to tell one devices from other?

Arseniy
  • 266
  • 2
  • 14
  • 2
    I most cases for a custom CDC/ACM device you only need an inf-file, linking usbser.sys with your VID-PID. Perhaps you might get a BSOD if the device doesn't function as usbser.sys expects it to. My guess, is that MS decided to be extra-carefull with letting anyone to use the default driver with their devices. For example, ST's virtual com port driver also uses usbser.sys, but they've signed the inf file, so it's installed without any warnings. – Flexz Jan 23 '23 at 11:10
  • I find with the WinDbg in STM32-CDC driver stack only a usbser.sys, eusbmon.sys, ACPI.sys and usbhub.sys. There is no any ST drivers. But on a PC that never use any ST ICs, the STM32-CDC detected as "Other Devices/STM32 Virtual ComPort". Can you give me a pice of advise, how to determine with WinDbg which vendor driver is using before usbser.sys? – Arseniy Jan 23 '23 at 11:29
  • I have no experience with WinDbg. You could try plugging the device in a linux host and check whether it is registered as a serial device. If it is, than probably usbser.sys would work with it. About device names in the Device Manager - these are derived from the device descriptors and could be overrided by a driver or just an inf-file. The same with USB pendrives, that need no drivers, but all are named in a different way. – Flexz Jan 23 '23 at 11:45
  • @Flexz There is no need for an INF-file if the device implements CDC-ACM. And no particular VID/PID is needed either. And your reference to ST probably refers to ST-Link debug adapter. They are composite devices consisting of a Virtual COM port, SWD debug server and optionally a mass storage device. The INF-file is for the SWD part only as the other two implement USB standards and are supported by Windows without the need for an INF-file or manual installation. – Codo Jan 23 '23 at 12:04
  • "And your reference to ST probably refers to ST-Link debug adapter." I create my own only USB-UART board with STM32F070. On my PC it detected as "Ports (COM and LPT)/COMx". On the PC of my colleague it detected as "Other Devices/STM32 Virtual ComPort". – Arseniy Jan 23 '23 at 12:09
  • Then you are likely using a VID/PID combination that the ST-Link driver feels responsible for. I can-t tell you who wins if two drivers fight for the same device. – Codo Jan 23 '23 at 12:14
  • "Then you are likely using a VID/PID combination that the ST-Link driver feels responsible for" within half an hour I will be able to check it :) – Arseniy Jan 23 '23 at 12:18
  • @Codo perhaps windows 10 changed something, but we are targeting wide and old PCs park, hosting mostly WinXP/7 and we always have to install a serial driver for our devices, and it is always solved by just a custom inf-file. And NO, I'm not that stupid to confuse ST-Link driver/device with a simple USB-CDC device. https://www.st.com/en/development-tools/stsw-stm32102.html – Flexz Jan 23 '23 at 12:28
  • @Flexz Windows 7 and in particular Windows XP are indeed different when it comes to USB driver support. You should probably have mentioned earlier that you are referring to so old systems. – Codo Jan 23 '23 at 12:35
  • @Codo You'll be surprised to know, how many of these 'so old' systems are still in use, especially on large organizations. – Flexz Jan 23 '23 at 12:38
  • @Codo I use the "USB Analyzer" to read VID/PID. My original ST-Link V3 has h483/h374F, the ST-Link V2 (which I broke off from the Nucleo board) has h483/h374B, my STM32-CDC has h483/h5740. So, the PID is not the same. – Arseniy Jan 23 '23 at 12:52
  • The VID 0483 is officially registered to STM. Their drivers can claim any devices in a wide range of PIDs if they have that VID. You will always be in danger of being in conflict with an STM driver as long as you use 0483. Use a separate VID instead. – Codo Jan 23 '23 at 13:04
  • And the VID/PID can also be found in your CDC example code and in the Windows device manager (it's included in the hardware ID and many other IDs). – Codo Jan 23 '23 at 13:07
  • @Codo I am very sorry! On the PC of my first colleague installed Windows 7. I have test the STM32-CDC on a PC of my second colleague (With Windows 10) and the board is detected as COM4. The second colleague PC also never use for any ST ICs (thus it has't any ST drivers). – Arseniy Jan 23 '23 at 13:20
  • Windows 7 is indeed different. See the added note in my answer. – Codo Jan 23 '23 at 13:56

2 Answers2

1

Question: Why the usbser.sys is not used with a USB CDC-ACM device?

Answer: usbser.sys is for USB CDC-ACM devices but your device isn't a USB CDC-ACM device.

Question: But I want to understand why the usbser.sys driver is not loading with this device?

Answer: see above

Question: What instruments shall I use to spot the difference and to tell one devices from other?

Answer: Use any tool or software that can read the USB device descriptor and configuration descriptor.

Question: How can the Windows understand that some USB CDC-ACM devices need the usbser.sys and the other don't need this driver?

Answer: It reads the device descriptor and configuration descriptor. If it contains a USB CDC-ACM compatible device, it will load usbser.sys. The requirements for USB CDC-ACM are described in the associated USB specification. In short, it requires two USB interface in a particular order, linked by an interface association descriptor and with the correct class code / subclass code (in the interface association descriptor).

Question: Is the difference in the descriptor or somwehere else?

Answer: Yes, the difference is in the descriptors (device and configuration).

Note: On Windows 8 and earlier, usbser.sys is not automatically loaded as mandated by the USB standard. A manual installation (possibly in conjunction with an INF-file) is needed.

Codo
  • 75,595
  • 17
  • 168
  • 206
  • The bigger part of your answer is a retelling of my question. A smaller part of your answer is the argument that the world is complex and incomprehensible. Your answer is unusefull. More precisely, your text is trying to seem like an answer, but it is not. – Arseniy Jan 23 '23 at 10:41
  • It is interesting, but typical for stack overflow to a question substitution from "how to do something" (or "why do I have something") to "what is it". When somebody asks the first question then someone implicit substitutes question and then answers on it. Basicly with wiki copypaste. From the side it seems: "if there are so many letters, this is probably the right answer!" But it is not. – Arseniy Jan 23 '23 at 10:51
  • I agree the answer was too long. So I've shortened it to answer your questions. – Codo Jan 23 '23 at 11:55
  • Thank you! These answers are much more good. But @Flexz indirectly indicated that my question was not quite correct. I thougt that STM32-CDC does't need an vendors driver and CY7C65213 does. But my investigation shows that they are both need vendors drivers. So the answer "Yes, the difference is in the descriptors" seems not quite correct. – Arseniy Jan 23 '23 at 12:05
  • I disagree with Flexz' answers. And why do you think STM32-CDC needs a vendor driver? I've implemented USB CDC on STM32 many times and it has never required a "vendor" driver. The ST-Link's are different. And CY7C65213 is not USB CDC compliant. – Codo Jan 23 '23 at 12:08
  • May be all of the PCs you test your STM32-CDC devices have the ST drivers? I surprised myself when my own only USB-UART board with STM32F070 detected on the PC of my colleague as "Other Devices/STM32 Virtual ComPort". – Arseniy Jan 23 '23 at 12:12
  • No, I don't have the ST drivers installed at all. I am aware of what unfortunate effects they have. And I test on Windows, Linux and macOS. You are likely using a VID/PID combination that the ST-Link driver feels responsible for, and in one case it wins over usbser.sys. Both drivers are probably fighting for it. – Codo Jan 23 '23 at 12:16
  • Your answer is missing a critical note - that it is only for Windows 10 and newer. – Flexz Jan 23 '23 at 12:32
  • @Codo "It reads the device descriptor and configuration descriptor." So, do you mean that somewhere in PnP manager (or, maybe in the usbser.sys) there is a full descriptor parser, that compare the descriptor with the standard CDC-ACM, and even if class/subclass codes are equal but the compliance with the standard CDC-ACM is not full, the usbser.sys will not load? If yes, what do you think where this parser is? And how can we see the reasons it decline some descriptor by this parser? – Arseniy Jan 23 '23 at 14:16
  • I'm not sufficiently familiar with the inner workings of Windows device drivers to answer it. But I know for certain that both the device descriptor and configuration descriptor must be read to decide what drivers are needed (at least the first time the device is connected). But honestly I'm confused about what you are trying to achieve and what your problem is. – Codo Jan 23 '23 at 14:30
1

If you open C:\Windows\inf\usbser.inf in a text editor you can see what kinds of devices it matches:

[Standard.NTamd64]
%UsbSerial.DeviceDesc% = UsbSerial_Install, USB\Class_02&SubClass_02&Prot_01
%UsbSerial.DeviceDesc% = UsbSerial_Install, USB\Class_02&SubClass_02

This part tells us that it only matches devices that have a compatible ID equal to "USB\Class_02&SubClass_02&Prot_01" or "USB\Class_02&SubClass_02&Prot_01". I am guessing your Cypress device either doesn't have those compatible IDs, or it has some other driver that is matching that device using more specific IDs.

You can see the compatible IDs of your device by double-clicking on it in the Device Manager and going to the Details tab. It also helps to view devices by connection so you can know whether you are clicking on an actual USB device or just one of its child devices.

David Grayson
  • 84,103
  • 24
  • 152
  • 189
  • There is a saying "If nothing helps, finally read the documentation" :) There is two Infineon/Cypress articles: "Differences Between the Microsoft® CDC Driver and the Cypress® CDC Driver - KBA91559" and "Binding a USB-Serial Device to a Microsoft® CDC Driver – KBA91366". The KBA91366 tells that it is possible to use usbser.sys (instead of Cypress driver) with CY7C65213. If you add this to your answer I will accept it. – Arseniy Jan 24 '23 at 06:49