Windows 10 CDC ACM device not recognised - tried the CDC ACM dual port example

[HattonLe]

Operating System

Windows 10

Commit SHA

1

Board

STM32F103 Bluepill

Firmware

I'm not having much luck in getting my custom CDC_ACM device to be recognised by Win10 Pro 2009 Build 19045.5737.

Device manager generally says Get Device Descriptor failed, status 0xC000009C, Problem 0xA.

So I tried the CDC ACMM dual port example and it too won't load under Win 10.

What happened ?

The device works perfectly in Ubuntu 25.10, but Win10 refuses to load it.

Just in case it was me, I tried the CDC ACM Dual port device from the examples folder.
The example device doesn't load in Win10 either (As a triple check the example device works fine in Ubuntu 25.10).

Does anyone have a working set of device configuration \ interface definitions proven to work in Win10?

How to reproduce ?

Build the example CDC ACM dual port for an stm32f103 Bluepill board.
Try it in Ubuntu 25.10 and it works.
Try it in Win10 and it won't load, (view hidden devices in device manager to see the faulty device).

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

Here is some technical info out of my Win10....

Edition Windows 10 Pro
Version 2009
Installed on ‎29/‎09/‎2024
OS Build 19045.5737

Device USB\VID_CAFE&PID_4002\30FF6B06304D453115410143 had a problem starting.

Driver Name: usb.inf
Class Guid: {36fc9e60-c465-11cf-8056-444553540000}
Service: usbccgp
Lower Filters:
Upper Filters:
Problem: 0xA
Problem Status: 0xC000009C

Device USB\VID_CAFE&PID_4002\30FF6B06304D453115410143 was configured.

Driver Name: usb.inf
Class Guid: {36fc9e60-c465-11cf-8056-444553540000}
Driver Date: 06/21/2006
Driver Version: 10.0.19041.4474
Driver Provider: Microsoft
Driver Section: Composite.Dev.NT
Driver Rank: 0xFF2003
Matching Device Id: USB\COMPOSITE
Outranked Drivers: oem26.inf:USB\COMPOSITE:00FF3003 oem27.inf:USB\COMPOSITE:00FF3003
Device Updated: false
Parent Device: USB\VID_1A40&PID_0101\7&dece10e&0&1

Screenshots

No response

I have checked existing issues, discussion and documentation

• I confirm I have checked existing issues, discussion and documentation.

[HiFiPhile]

Well that's weird, I mostly work on Windows 10 22H2 and never met this issue with daily cdc_dual_ports build on different MCUs.

Maybe try another PC/port/hub ?

[HiFiPhile]

Can't reproduce with STM32 Mini V2.0 + Windows 10 Pro 19045.6575.

[mudrovc]

I'm using two CDC ports on windows 10 - it's recognized normally in windows.

[HattonLe]

My board is an AliExpress WeAct Studio v1.1 STM32F103, with the yellow pin headers. (The STM32 MCU was a real one, but just in case I swapped it out for a STM32F103 purchased direct from STM).

My test setup is Dell M6700 laptop, with a 7 port power switchable hub (supposed to be USB 3.0 but its not) connected to one of the docking station USB 3.0 ports. Dual bootable with Win10 and Ubuntu 25.10. (The Win10 is a pretty minimal airgapped installation which I only use for NTFS drive recovery when Ubuntu goes screwball occasionally).

My usual testing is via plugging the device into the 7 port hub.

Did some more experiments - as follows with no luck, same results each time -

• Connecting via a different USB cable.
• Connecting via a Dell M6700 USB3.0 port (on righthand side).
• Connecting via a Dell M6700 USB2.0 port (on lefthand side).

Each time in Device Manager, viewing hidden devices, I uninstalled the errored device and then did a scan for new hardware.
I also tried uninstalling the errored device and then physically unplugging \ plugging in the device.

Attached screenshot of Device Manager properties for the errored device.

[HiFiPhile]

What do you get with CFG_TUSB_DEBUG=2 ?

[mudrovc]

I'm at the begging of tinyusb learning curve - but with my USB expiriance - it looks like device descriptor/config descriptor problem.

Normally Linux is much more tollerant to annomalies in descriptors.

Have you tried on a different windows machine?

[HattonLe]

I have a complete duplicate M6700 machine I use as a spare system - I just tried the device with that - no change in result.
I already have a USB dual serial port attached to my STM32 device (for developing my custom device, currently attached to uart2 & uart 3).
I just recompiled device with CFG_TUSB_DEBUG=2, moved my serialport cable from STM32 uart2--> STM32uart1 and then tried it on duplicate M6700 system and it worked (I have a debug trace of that attempt).... something funny going on here, so will reboot to Win10 & try device again using this M6700 to see what happens.

[HattonLe]

Hmmm definitely something weird going on here.
After compiling the dual cdc acm example with CFG_TUSB_DEBUG=2, I couldn't get the USB device to go wrong. I went thru combinations of my USB dual serial port connects to uart2 and uart 1 just to make sure there was no parasitic power issues happening thru the uart signal lines.
I then recompiled it to turn off the debug logging, and I couldn't get it to go wrong in Win10 at all. My thinking at this stage was perhaps there was something uninitialised in the code such that after using it with debug mode it was now 'initialised' which fixed the problem.

Note - my USB device is in my USB Hub position 6, and my STLink dongle in Hub position 7 next to it. The extra USB dual serial ports are on a seperate port to the Dell M6700, so totally independent. The STLink SWD hookups go to the STM board for programming and stay attached during testing. My usual usage after a test run is, hack\recompile code, power cycle both USBs off and on (so Ubuntu USB host is happy), reprogram device, cycle power to both off and on (to launch new code from scratch) and then the next test run... For a Win10 test run its boot up, and then power on both USBs.

So... went back to my custom USB device code, (which has debug logging enabled). The device worked in Ubuntu ok, debug output with TinyUSB stuff in it looked ok, so all good so far, then tried Win10.
In Win 10 the fault was back again, I was getting an initial device power up hello in my debug output, but nothing else though.

So.. I thought lets disconnect the SWD wires from the STLink, so I only have to power up just the USB device.... get same error, same one line power up hello debug output message. Win10 didn't react to the device power up at all.

Whislt the USB device was still on, I then powered up the USB STLink in next HUB position.... and wooah.... I get a load of TinyUSB debug logging appear from my USB device! (Win10 beeped so USB device detected, but still ends up with the same error).

NOTE the STLink device is not even connected to my USB device. Somehow, powering on the STLink device in the Hub port position 7, is causing the USB device in hub position 6 to do TinyUsb activity.

Just did a test of plugging the USB device (without STLink attached) into the other Dell M6700. I get the debug logging saying power on hello and TinyUSB saying its getting descriptor requests but still the same WIn10 device error at the end of the day. Will go thru all this testing again tomorrow to reduce, refine and replicate to see if anything new pops up.

[HattonLe]

Back... after hours and hours of testing. I had two seperate problems, one hardware (my hub) and one code (usb_descs.h).
For the USB hub - I still have no idea why the dual CDC ACM example together with my hubs port 6 & 7 were erroring \ operating like that. Its 100% repeatable after reloading the STM32 with my broken Tinyusb app code and then overwriting it with the example app with debug turned on. So I have ordered a new switchable USB 3.2 hub (well I hope its a real USB 3.2 hub - there are so many fakes out there).

For the coding error I eventually tracked it down to ITF_NUM_TOTAL being wrong (during all my tests trying to get it to work when changing between different configurations I didn't check ITF_NUM_TOTAL was correct.

For the latter problem, I didn't realise until after hours digging into TinyUsb that the stack is conditionally compiled depending on for example the value of CFG_TUD_CDC. This value dependency makes it difficult to incorporate TinyUsb as an independant library in a build.
i.e. it nicer to be able to differentiate between configuring TinyUsb for building and configuring TinyUsb for runtime usage.

In my app I use TinyUsb as an imported library built for CDC, which I can then at runtime setup for USB configure of 3 CDCs - this makes it very easy for me to switch between USB configs for running other tests etc. The app code has a single source file to holding the USB descriptors that isn't used by the TinyUsb stack during building. This split adds very little overhead to the existing code base.

The good news is situation kinda sorted, new hardware on its was and I've learnt a lot more about the TinyUsb internals. Now to get 4 CDCs working!

[HiFiPhile]

For the hub issue I think a hardware analyzer is needed in this case. When HS host talk to FS/LS device there is a transaction translator (TT) inside the hub chip who does the job, some chips can do funny things.

For library use if you are not size restricted you can max out every config like 4CDC +4HID while building, so all you need is change descriptor afterwards.

It's hard to balancing those wants more function and code size, actually TUSB is already not so "tiny", a hard crafted DFU bootloader is less than 4k (Nuvoton chips has 4k LDROM) while with TUSB 8k is needed.

[HattonLe]

A USB hardware analyser would be nice :o) - I'll read up on how USB hubs work (they are something I have used for decades but never needed to know about how they work internally).

Yes bloat is the devil. I prefer barebones approach using the lowest level tech you can get away with. The higher the tech you platform onto the greater the chance of coming a cropper to mistakes that aren't yours.

[HattonLe]

Thanks to all for feedback and advice to help me get unstuck. Much appreciated.

For anyone using Ubuntu to develop USB devices... Attached is a useful bash script for Ubuntu that I run as sudo to reset the USB subsystem between tests of 'iffy' USB devices.

ResetUSB.sh