I'm working on a custom board using a Raspberry Pi computer on module (COM) (info and schematics here: http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/. The board is based on the raspberry Pi model B (schematic here: http://www.raspberrypi.org/model-b-revision-2-0-schematics/) as it uses the LAN9512 USB hub and Ethernet controller IC in the same configuration as Rasberry Pi model B (relevant part of schematic attached). The first downstream USB port on my board is connected to an Arm Cortex M3 MCU on the same board, and the other one is connected to USB connector for plugging in external USB devices. The Ethernet is connected to a molex RJ45 jack with integrated magnetics.
The problem is that while other parts of the board are working fine so far, I can not get the LAN9512 to work. I plug in the raspberry Pi COM, and access it through a serial console. I can see the LAN9512 is detected and correct drivers are loaded in syslog output. However, ethernet does not work when a cable is connected, nothing happens when a USB device (be it mouse, keyboard, flash drive) is connected to the USB port, and the ARM Cortex MCU does not come up in devices as a USB COM port (as it is configured in software). Furthermore the Ethernet "LINK" light is always ON. Basically, everything looks good from the upstream port to raspberry pi as the LAN9512 is detected and drivers loaded, but nothing downstream works, not even generating any messages in syslog or debug log on the raspberry pi COM.
I've tried everything I could think of so far. I checked for shorts on the LAN9512 IC, I replaced the IC with a new one (same behavior), I checked voltages on all pins of the LAN9512 IC and compared them to a working raspberry Pi voltages on the same IC (only difference is LINK led signal, as shown in attached document). I made sure the crystal is oscillating with an o-scope. I removed the protection diodes U401. I removed the Arm Cortex MCU. I removed the Ethernet Jack. I made sure all components are properly populated. I tried a new COM module.
When I drive the GPIO6 line on the COM module low, which is tied to the RESET of the LAN9512 and back to high again, I get
the following output:
[ 1041.165108] usb 1-1: USB disconnect, device number 2
[ 1041.165143] usb 1-1.1: USB disconnect, device number 3
[ 1041.165408] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet
[ 1041.165472] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Back to high
[ 1137.826768] Indeed it is in host mode hprt0 = 00021501
[ 1138.006764] usb 1-1: new high-speed USB device number 4 using dwc_otg
[ 1138.006958] Indeed it is in host mode hprt0 = 00001101
[ 1138.207088] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
[ 1138.207123] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1138.213408] hub 1-1:1.0: USB hub found
[ 1138.213589] hub 1-1:1.0: 3 ports detected
[ 1138.486807] usb 1-1.1: new high-speed USB device number 5 using dwc_otg
[ 1138.587054] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 1138.587086] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1138.590152] smsc95xx v1.0.4
[ 1138.656927] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:02:d4:3b
[ 1138.839255] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
which is the same as when I do that on a raspberry pi model B (save the last line). I double and triple checked the schematic and compared it to the model B schematic linked above. I paid attention to routing of the USB lines in layout and they are as equal as I could make them provided my design software does not have the means of routing differential pairs.
The layer stackup is TOP, inner signal, inner gnd, bottom, and the parts of the board of concern are attached. I read all documents I could find relating to LAN9512 and could not find anything that explains this situation. Nor do I understand why the LINK led is always ON.
My question is whether anyone with more experience than me, with this IC or with Ethernet and USB hubs in general, can spot a potential problem? Can all this be due because USB and ETH lines are not differentially routed? I would expect I would get some errors and all kinds of erratic behaviour if that was the case?
Attached are LAN9512 schematic page, board layout, dmesg log on the rapsberry pi boot-up, and voltages as measured on my board and on a working model B.
LAN9512 Documentation is here: http://www.microchip.com/wwwproducts/Devices.aspx?product=LAN9512
Any feedback or ideas greatly appreciated.
Schematic of LAN9512 here: https://drive.google.com/file/d/0B0QS1nQxzbYMMHlfNzF1S01uTkE/view?usp=sharing
Voltages on model B and custom board here:
https://drive.google.com/file/d/0B0QS1nQxzbYMMDBfQVNvei1xZTQ/view?usp=sharing
PCB Layers:
TOP
https://drive.google.com/file/d/0B0QS1nQxzbYMV0F4NWNtZFgwbXM/view?usp=sharing
Inner Sig:
https://drive.google.com/file/d/0B0QS1nQxzbYMWWdyUk1Qc1dxdlE/view?usp=sharing
Inner GND Plane:
https://drive.google.com/file/d/0B0QS1nQxzbYMRUhqbTNOME1yREk/view?usp=sharing
Bottom:
https://drive.google.com/file/d/0B0QS1nQxzbYMN05lZnNmYTdzdUE/view?usp=sharing
Best Answer
I resolved the problem, but it took re-manufacturing the board. The problem seemed to be with the routing and layer stack-up. The USB and Ethernet traces did not have correct impedance due to two reasons.
Firstly, the track geometry was not correct for 90 ohm (USB) and 100 ohm (ETHERNET) differential impedance. If your layout software does not support differential routing (eg: Altium does), then you will need to use something like SaturnPCB to calculate the track geometry and manually route the traces accordingly (I had to do this).
Secondly, and most importantly, the layer stackup was not correct to support USB and Ethernet high speed traces.The stack-up was TOP-INNER SIG-GND-BOTTOM and the high speed traces where routed on top layer. USB and ETH traces require a solid ground plane underneath and since this was not the case on my board it really messed up the signal integrity. Putting a solid ground plane (hence changing the stack-up to TOP-GND-INNER SIGNAL-BOTTOM) fixed the signal integrity issues.
I also cleaned up the placement of decoupling caps around the LAN9512 IC.
After these changes, the new board worked without problems. If you're using the raspberryPi to clock the LAN9512 (as B+ with LAN9514 does), then you also need to configure the Pi to output a clock signal. You can find info on this here: http://www.elektricks.net/raspberry-pi-compute-module-general-purpose-clock/ If you have a separate oscillator for the LAN9512 then ignore this paragraph.
Hope that helps!