CDC class refuses to enumerate in my FreeRTOS

[lost vapor]

I’ve spent days getting a minimal FreeRTOS application running on the Pico W and printing “FreeRTOS is running!” over USB, but despite the code building and flashing cleanly, Linux never creates the /dev/ttyACM0 port. I verified the hardware and cable by successfully building and running TinyUSB’s CDC dual-ports example (which did enumerate correctly), so I know the Pico and host can do CDC-ACM. In my own app I created a FreeRTOS USB task that calls tud_task() every 10 ms, called tusb_init() (or tud_init(NULL)) after stdio_init_all(), and even added a custom tusb_config.h with CFG_TUD_CDC, buffer sizes, endpoint settings, and ensured the include paths in CMake picked it up. I also tried forcing compile definitions and adjusting the CMake include order. Yet when I plug the Pico in normal (non-BOOTSEL) mode I only see “new full-speed USB device” in dmesg and no cdc_acm … ttyACM0 binding. I've chased port assembly, config headers, SDK vs. raw TinyUSB stacks, buffer macros, and initialization order—all to no success . Any insight into why the cdc class refuses to enumerate in my freertos build would be greatly appreciated 🙌

I can provide any of the files that you might want to see to better help

[near girder]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[lost vapor]

CDC class refuses to enumerate in my FreeRTOS

[dark island]

I've dealt this problem with the Pi Pico before

trying to remember what I did

I think you have to reset the chip while its plugged in to USB

did you download usbtty?

https://p.fr33tux.org/76c522

I found this notes.md from when I was messing around with the Pi Pico a year or two ago

[lost vapor]

Hey, thanks for the tip—but resetting while plugged in (or using BOOTSEL) just drops you into the UF2 bootloader, it doesn’t change how your application’s USB stack comes up once it’s running. And usbtty is just a host-side serial client—it only matters after Linux has already bound /dev/ttyACM0, which in my case never happens because the host times out before I've ever answer its GET_DESCRIPTOR requests.

In my situation the Pico never even completes USB enumeration (i see error like -110 in dmesg), so there isn’t a CDC port for usbtty to open. The real issue is that TinyUSB’s device stack isn’t initialized and polled soon enough, so the control endpoint never responds and the host gives up. That's how I've seen it atleast

[near girder]

@lost vapor Has your question been resolved? If so, type !solved :)