USB device not recognized on a custom MCU board: how do I debug a failed enumeration?

At attach the host sees a pull-up on one data line: 1.5 kΩ to 3.3 V on D+ identifies a full-speed device, and the same on D- a low-speed one. The host then resets the port by holding both lines low for at least 10 ms and sends a GET_DESCRIPTOR request for the device descriptor to address 0 on endpoint 0. Next come SET_ADDRESS, the full 18-byte device descriptor, the configuration descriptors and finally SET_CONFIGURATION.

Your error appears at the very first request. The host detected the pull-up, so something is attached, but it got no valid answer. On Linux, -71 is a protocol error (a garbled or missing response), while -110 would be a plain timeout. That points to the physical layer, the clock, or firmware that is not servicing endpoint 0, rather than to the descriptor contents.

Check the clock first. Full-speed USB requires the data rate to be accurate to ±0.25 %, and the USB peripheral needs exactly 48 MHz. An internal RC oscillator is generally not good enough unless the MCU has a clock-recovery feature that trims it against the host's start-of-frame packets, and that feature must be enabled. If the development board has a crystal and your board does not, or uses a different crystal frequency without the PLL settings being changed, the device answers at the wrong bit rate and the host sees garbage.

Verify by outputting the system clock on an MCO pin and measuring it, or by checking that a UART at a known baud rate prints correctly. On an STM32F103, for instance, the usual arrangement is an 8 MHz crystal multiplied to 72 MHz with the USB prescaler set to 1.5 to give 48 MHz.

Then the wiring. Swapped D+ and D- is the most frequent layout mistake: the pull-up then sits on the wrong line, the host sees a low-speed device and every request fails. Check the connector footprint against the datasheet pin numbering, viewed from the correct side. Check the pull-up too: some MCU families have it built in and switched by firmware, while others, such as the STM32F103, need an external 1.5 kΩ from D+ to 3.3 V.

Other hardware checks: series resistors on the data lines only if the MCU's datasheet asks for them, no large capacitance on D+ and D- (an ESD part meant for slow signals can be too much), a solid ground through the connector, and a 3.3 V rail that stays stable when the cable is plugged in.

If the hardware checks out, look at firmware differences between the two boards. On STM32 parts with the OTG peripheral, VBUS sensing is a classic trap: if it is enabled and the sensing pin is not wired to VBUS on your board, the stack never believes it is connected, so disable VBUS sensing or wire the pin as the datasheet recommends. Make sure the USB interrupt is enabled and not starved by long critical sections, since setup packets must be handled promptly.

Also confirm that endpoint 0's maximum packet size in the device descriptor matches what the stack is configured for, and that the heap and stack sizes are large enough for the USB class you use. An allocation failure during class initialisation leaves a device that attaches but never answers.

Tools that shorten the search: on Linux, run dmesg -w while plugging in and lsusb -v once the device enumerates; on Windows, the device manager's event details show how far enumeration got. A software capture (usbmon with Wireshark on Linux, or the equivalent capture driver on Windows) shows the control requests and responses, which is enough when the device answers but with wrong descriptors.

For a failure at the first descriptor read, a software capture shows only the error, so look at the wire. Use an oscilloscope to check levels and bit timing (a full-speed bit lasts 83.3 ns) or a logic analyser with a USB decoder that samples at several times 12 MHz. Try a different cable and a port directly on the PC as well.