I'm designing a USB-to-Ethernet adapter (actually a prototype of a piece of a larger board). As those following my questions will know, I've had some ups and downs getting the USB part working, but now it shows up as a USB hub in Linux and I can use devices connected to it. Now for the Ethernet part.

As far as I can tell, I have followed the various guidance in the datasheet. The schematic is shown below. I can confirm that VDDCORE is being generated correctly and that there is a 25MHz sine wave on the 25MHz crystal - so the chip is showing some signs of life. But it doesn't show up in a scan of the USB bus. Both jumpers (JX1 and JX2) are installed, though I've tried without as well.

What can I do to try to debug this? What should I be checking for on the board? Have I made any obvious mistakes?

• From your previous inquiries, you are connecting all this to Raspberry Pi. Rpi has full-sized USB 2.0 HS host, 480 Mbps. Why you are crippling your design to 12 Mbps level? – Ale..chenski Aug 3 '18 at 20:08
• Because I don't need anything better. – Tom Aug 6 '18 at 9:44

The major mistake in your schematics is that the nRESET signal (pin 24) doesn't follow the delay specifications. The deassertion of this signal must be delayed until all supply voltages reach valid level:

In your schematics the nRESET is tied directly to power rail, which obviously violates specifications. If the LAN7500 IC can't receive "valid reset", it will be internally screwed and won 't work.

To handle this signal properly it is highly recommended to use a "voltage supervisor" IC like MAX809. This method will provide guaranteed reset under various power-on and brown-out conditions. In most simplistic/cheap case you can use a RC-delay on this pin, but this will be a gamble in unstable power-on situations.

ADDITION: Another typical problem with embedded hubs and embedded devices is the sequencing of VBUS_DET on LAN9500 side. To connect to hub, the LAN9500 must pull up D+ high when it sees VBUS_DET, and not before that. You should obtain scope traces of what is going on D+/D- wires between the hub and LAN. Theoretically the connect event should NOT occur before the hub is ready to operate (be enumerated and such). If the connect event (D+ pull HIGH) occurs before that, the hub status reporting might be screwed. To test if this is the problem, toggle momentarily the VBUS_DET to ground and see if the hub/host would start to recognize the connect event and starts doing something (USB_RESET etc. etc).

To make the connection correctly and get proper sequencing reardless of power ramp rates, it is advisable to connect the VBUS_DET to the power control pin on hub side, PWRON1, with proper polarity. The PWRON1 pin will be logically inactive until the hub is fully enumerated and operational, which will ensure that LAN9500 will start the connect process after all is ready.