0
\$\begingroup\$

I have a PCB with a USB2244 USB to SDIO bridge IC connected to a Raspberry Pi Compute Module 3+. I (think I) designed based on the schematic circuit for the USB224x evaluation kit EVB-USB2240-IND. When I connect the evaluation kit to the USB port on the previous revision of my PCB, the Pi CM sees it just fine. My new PCB has the USB2244 onboard with no external USB ports. Unfortunately, it doesn't seem to be enumerating properly. It starts up, appears to talk briefly, and then shuts down.

In order to isolate the Pi CM as a configuration issue, I unplugged the compute module and soldered a USB-A cable to the circuit to plug into my Windows laptop and had similar issues. I then plugged the same USB cable into a Pi 4 and logged USB packets with Wireshark, but I don't really know how to interpret those logs properly.

Here is my schematic for the USB2244. The reset and USB data lines go to the Compute Module socket. Note that the USB2244 datasheet claims that it has all required termination/pull resistors for the USB data lines built in.

Circuit schematic

Here's what I know from testing so far. I'm not sure what to look at next. Feeling stumped.

  • The USB data traces on my PCB were properly specified for controlled impedance.
  • The RST_PN pin remains high throughout the failed enumeration.
  • The USBDP line on my PCB does float high before connecting the USB cable, so it is attempting to advertise itself.
  • The USBDP line stays high after the failed enumeration.
  • The oscillator does run for a short period of time during enumeration and does look to be approximately 24MHz, but it then stops. I don't know exactly when this happens relative to the rest of the process.
  • The USB2244 does not show up in a lsusb output on the Linux system after the enumeration failure.
  • The SD card I'm testing with is known-good.
  • The USB data edge transitions look reasonably clean, even with the test cable tacked on.
  • When plugging my test cable into another Linux system, I get the following outputs in dmesg (mostly errors). There was an SD card plugged in for this test. The "attempt power cycle" line probably doesn't accomplish anything because the USB2244 is self-powered from my PCB.
[157703.323082] usb 1-1.1.3: new full-speed USB device number 28 using xhci_hcd
[157703.423293] usb 1-1.1.3: device descriptor read/64, error -32
[157703.643243] usb 1-1.1.3: device descriptor read/64, error -32
[157703.863053] usb 1-1.1.3: new full-speed USB device number 29 using xhci_hcd
[157703.963263] usb 1-1.1.3: device descriptor read/64, error -32
[157704.183265] usb 1-1.1.3: device descriptor read/64, error -32
[157704.303438] usb 1-1.1-port3: attempt power cycle
[157704.963098] usb 1-1.1.3: new full-speed USB device number 30 using xhci_hcd
[157704.963283] usb 1-1.1.3: Device not responding to setup address.
[157705.183259] usb 1-1.1.3: Device not responding to setup address.
[157705.403150] usb 1-1.1.3: device not accepting address 30, error -71
[157705.503069] usb 1-1.1.3: new full-speed USB device number 31 using xhci_hcd
[157705.503218] usb 1-1.1.3: Device not responding to setup address.
[157705.723203] usb 1-1.1.3: Device not responding to setup address.
[157705.943116] usb 1-1.1.3: device not accepting address 31, error -71
[157705.943460] usb 1-1.1-port3: unable to enumerate USB device

This is the Wireshark USB packet capture log. I believe the 1.8.1 device is my USB2244 -- I plugged it into what I believe to be Port 3 of an external hub connected to my Pi 4.

This is a logic analyzer dump that should line up with the Wireshark packet capture. I see a bunch of "Unexpected packet SETUP" going on.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ When testing with the PC, are you sure you got the DP and DN the right way? If DP is pulled up, the PC should not say that a low-speed device is detected, the PC might see that DN is pulled up. And your crystal circuitry is missing the 1 Mohm bias resistor, it can cause the oscillator to not work. \$\endgroup\$ – Justme May 18 '20 at 9:27
  • \$\begingroup\$ I suppose the cable I chopped up could be swapping the colors from the defacto standard, I'll take a look. \$\endgroup\$ – Joe Baker May 18 '20 at 19:22
  • \$\begingroup\$ Yup, it was backwards. I guess there's two "standards" where white/green are D+/D- or the other way around. Still having errors but not quite the same ones. Will update the question accordingly. \$\endgroup\$ – Joe Baker May 19 '20 at 3:00
  • \$\begingroup\$ I did turn out to be the 1M resistor if you want to add that as an answer I'll accept it. \$\endgroup\$ – Joe Baker May 26 '20 at 7:20
  • \$\begingroup\$ I changed my existing wrong answer to the correct one. \$\endgroup\$ – Justme May 26 '20 at 10:33
1
\$\begingroup\$

The crystal oscillator circuit is not oscillating because there is a missing 1 Mohm bias resistor between the crystal terminals.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.