ESP32-C3-WROOM-02 no USB enumeration "device descriptor failed" / "Code 43"

[rapsma]

Hi all,
I'm working on a board based on the ESP32-C3 WROOM module. On the board I designed and had manufactured, I have GPIO18 to USB-DN and GPIO19 do USB-DP. As far as I know this should be correct. When connecting the device, it shows up in the Window 10 device manager as an "Unknown USB Device (Device Descriptor Request Failed)". Inspecting the details of the device in Device Manager shows the message:

Windows has stopped this device because it has reported problems. (Code 43)

A request for the USB device descriptor failed.

The ESP32 otherwise functions fine. It can be programmed OK through the UART on RX/TX. All GPIO's work, including 18 & 19 when they're configured as regular inputs or outputs. All other peripherals insofar as I've tested them, work fine as well, including WiFi. The WROOM modules run perfectly fine and very stable, suggesting it's not a power supply issue.

I've tried several WROOM modules from two different shipments/suppliers and they all exhibit the same behavior. The problem exists in brand new devices that I have not downloaded any firmware into, as well as devices I've programmed through UART.

I've made several test setups with wires soldered directly to the WROOM module; the behavior is always identical.

I've included 22R resistors in USB-D+/D- and I've left them out: no difference. I've included TVS diodes on D+/D- and removed them: no difference.

On the original board I made, the USB D+/D- are short (ca. 20mm) traces, 0.2mm width, running parallel, mostly surrounded by GND pours and they are of equal length. As said, sloppy flying wire setups show the exact same behavior. Other USB devices I've made in the past work just fine (CP2102, CH340 etc.)

I've tried several USB ports on my computer, distributed across three different hardware USB bridges (two on-board and one PCIe addon card). The problem always remains the same. All other USB devices connected to the same ports function perfectly.

I have spent quite some time searching for solutions to this problem online, and have found a few instances of same problem. E.g.:
https://esp32.com/viewtopic.php?t=5513 (no solution ever materialized; poster missing-in-action)
https://www.reddit.com/r/esp32/comments ... _problems/ ('solution' offered is not consistent with Espressif's documentation and examples shown elsewhere where the ESP32-C3 should enumerate as a regular USB-UART bridge)
viewtopic.php?t=35665 (misconfiguration of the GPIO's is not the problem in my case; it also occurs with virgin/factory-fresh devices, and the problem also occurs in 'joint download boot' mode).

The most basic test setup I'm using is:
* EN pulled up to 3V3 with 10k and decoupled to GND with 1uF, with a microswitch used as RST button.
* GPIO2 + GPIO8 pulled up with 10k to 3V3.
* GPIO9 pulled up to 3V3 with 10k and a microswitch as 'BOOT' button to GND.
* 3V3 from an AMS1117 (fed by 5V USB VBUS). Decoupled on both 5V and 3V3 side with 4u7 ceramic cap.

I have a feeling I'm overlooking something very basic/fundamental, but for the life of me, I can't figure out what it is. Any suggestions of things I can try would be welcome.

[ESP_Sprite]

Hm, nothing that you wrote stands out as something that would break USB... Some ideas: Can you change other things? E.g. use a different computer (or e.g. a Raspberry Pi), or if you don't have one, perhaps try a Linux live-CD (or more likely live-USB-stick) and see if the device enumerates there? Grab a pre-existing devkit that uses USB-serial-JTAG (e.g. the Adafruit QT Py ESP32-C3, or one of those ESP32-C3 Super Mini boards) and see if that works?

[rapsma]

Thanks so much for your answer and your suggestions for trouble-shooting. They make perfect sense; I really should have tried the other computer already. I don't have a ready-made DevKit handy, but I could have (should have) ordered one.

However...yesterday after posting this thread I did one 'final' experiment to put my mind at ease. And guess what...it works like a charm. I think the problem has been poor physical layout all along. Apparently the ESP32 is just more sensitive to this than devices like CP2102 and CH340. The tests I had done before involved boards that required small, manual bug-fixes and entirely handmade contraptions, in the expectation that USB would be rugged enough to at least enumerate under less than ideal conditions. I suppose that it really isn't and layout is every bit as critical as all documentation out there also suggests.

I've included the schematic, PCB layout and a photo of the working test setup. It looks a little shoddy because it's a handmade PCB that I made while dinner was cooking.
Note that the capacitors that decouple USB-DP and -DN are not populated as per ESP documentation. The series resistors in both data lines are 10R.
Pullups on EN, GPIO2, 8 and 9 are 10k. The capacitor between EN and GND is 470nF. I don't think any of these values directly affect USB enumeration although I can imagine that making the cap too small (or leaving it out) can result in a brownout condition as power comes on, making the startup (and USB enumeration) less reliable. However, I had previously already excluded this in earlier tests.

So my conclusion remains that all my earlier setups suffered from (too) serious physical/layout problems.

[ESP_Sprite]

However...yesterday after posting this thread I did one 'final' experiment to put my mind at ease. And guess what...it works like a charm. I think the problem has been poor physical layout all along. Apparently the ESP32 is just more sensitive to this than devices like CP2102 and CH340. The tests I had done before involved boards that required small, manual bug-fixes and entirely handmade contraptions, in the expectation that USB would be rugged enough to at least enumerate under less than ideal conditions. I suppose that it really isn't and layout is every bit as critical as all documentation out there also suggests.

That is interesting. As far as I understand, you can (theoretically) run USB full speed over a pair of coat-hangers and it should still connect, and my experience with the ESP32C3 is not much different (if I route it on my own PCBs, I just keep the traces close and that's about it wrt signal integrity). I'm wondering if your hacking caused something else that *did* corrupt the signal... perhaps something like hygroscopic flux that got conductive enough to act as a pullup on D- or something?

[rapsma]

I like the coat hanger idea! The flux hypothesis surely would have shown up on poking around with a multimeter - if it were low impedance enough to be a significant problem, which I find hard to believe to begin with.

It's odd; my experience with other USB devices echoes yours, in that it'll pretty much work, regardless. For some reason, it's different with the ESP32-C3.

I might try to do some further diagnosis on the original board it all started out with. In case I find anything, I'll post back.

[rapsma]

OK, that was quicker than I anticipated. On the original board I did most testing with, there was a provision for a separate USB-UART bridge (a 'just in case' addition for prototyping) that I didn't end up using in the prototype. However, it did have traces for USB-D+ and D- routed to the unpopulated footprint from the USB connector. Having learned that the routing is a little more critical than I had anticipated, I cut those 'spare' traces on one of the proto boards...and the USB came alive on the ESP32. Apparently, the effective T-shaped traces picked up noise or created reflections (I suspect the latter) that spoiled the broth.

What still puzzles me is that in another setup that I manually wired and that did not feature a similar T-shaped trace pattern with dangling ends, the problem also existed. So maybe the coathanger approach is a little too optimistic.