link2cory
Posts: 9
Joined: Tue Mar 06, 2018 6:16 pm

LAN9514 chip troubleshooting

Tue Jun 19, 2018 6:33 pm

Hi All,

I am troubleshooting a cm3 board that was designed by our hardware engineer. The design uses a LAN9514 to act as a usb hub (and future ethernet port) but I have been having trouble getting the thing to enumerate.

Here is my relevant dmesg output: I can supply the full output if you need

Code: Select all

[    0.000000] Kernel command line: bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:8B:14:1A vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=505935c8-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait usbcore.use_both_schemes=Y
[    0.059969] usbcore: registered new interface driver usbfs
[    0.060149] usbcore: registered new interface driver hub
[    0.060256] usbcore: registered new device driver usb
[    0.245612] usbcore: registered new interface driver lan78xx
[    0.247951] usbcore: registered new interface driver smsc95xx
[    0.722267] dwc_otg 3f980000.usb: DWC OTG Controller
[    0.724588] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    0.726956] dwc_otg 3f980000.usb: irq 62, io mem 0x00000000
[    0.733965] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.736287] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.738600] usb usb1: Product: DWC OTG Controller
[    0.740858] usb usb1: Manufacturer: Linux 4.14.34-v7 dwc_otg_hcd
[    0.743164] usb usb1: SerialNumber: 3f980000.usb
[    0.750993] usbcore: registered new interface driver usb-storage
[    0.796745] usbcore: registered new interface driver usbhid
[    0.799061] usbhid: USB HID core driver
[    2.188375] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    2.442285] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    2.451458] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.792041] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    2.922308] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    2.931796] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.035708] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:8b:14:1a
[    3.332054] usb 1-1.4: new full-speed USB device number 4 using dwc_otg
[    3.906075] usb 1-1.4: New USB device found, idVendor=0a12, idProduct=0001
[    3.906089] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    3.906108] usb 1-1.4: Product: CSR8510 A10
[    4.497056] usbcore: registered new interface driver btusb
[    4.985121] usbcore: registered new interface driver smsc9500
[   13.445388] usb 1-1.1: USB disconnect, device number 3
[   13.445694] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet
[   13.482681] usb 1-1.4: USB disconnect, device number 4
[   13.712007] usb 1-1: reset high-speed USB device number 2 using dwc_otg
[   13.922000] usb 1-1: device descriptor read/64, error -71
[   14.251999] usb 1-1: device descriptor read/64, error -71
[   14.582032] usb 1-1: reset high-speed USB device number 2 using dwc_otg
[   14.792483] usb 1-1: device descriptor read/64, error -71
[   15.132000] usb 1-1: device descriptor read/64, error -71
[   15.462000] usb 1-1: reset high-speed USB device number 2 using dwc_otg
[   15.902025] usb 1-1: device not accepting address 2, error -71
[   16.112003] usb 1-1: reset high-speed USB device number 2 using dwc_otg
[   16.551998] usb 1-1: device not accepting address 2, error -71
[   16.552083] usb 1-1: USB disconnect, device number 2
[   17.082004] usb 1-1: new high-speed USB device number 5 using dwc_otg
[   17.291998] usb 1-1: device descriptor read/64, error -71
[   17.622007] usb 1-1: device descriptor read/64, error -71
[   17.952027] usb 1-1: new high-speed USB device number 6 using dwc_otg
[   18.162024] usb 1-1: device descriptor read/64, error -71
[   18.492041] usb 1-1: device descriptor read/64, error -71
[   18.612045] usb usb1-port1: attempt power cycle
Lots of error -71 which I haven't been able to get a clear idea of the meaning of.

Most of the issues I have found that look like this seem to be people hooking up a usb device that wants to draw too much current, but our power supply is quite beefy (6-8 amps) and the designer of this board did not hook up the overcurrent signals on the usb-load switches to the pwrcntrl pins. So the usb devices should be getting plenty of current and it should not be possible for the overcurrent state to be reached. Yes I know this probably isn't the best design. I will push for overcurrent protection in the next revision.

I am using a fresh raspbian stretch image on the cm3, (4.14.34) but I also compiled the drivers distributed directly by Microchip and have also tried those in lieu of the drivers that are present in raspbian by default.


You may also notice upon scrutiny of my dmesg output that I have tried with "usbcore.use_both_schemes=Y" in my cmdline.txt. When I first did this it seemed to work. I got a successful enumeration of the usb hub but not the bt800, and all four pwrcntrl pins went high.

HARDWARE

It is worth mentioning also that this revision currently does not make use of the ethernet port functionality of the LAN and so leaves the data pins unconnected (although automdix_en is pulled high)

I would still expect an eth0 interface in this case, but there is none in ifconfig.

It is probably also worth mentioning that the LAN9514 is also hooked up to an unflashed eeprom. My understanding from the LAN9514 datasheet is that this shouldn't be hurting anything, we are just unable to benefit from any configuration options until the eeprom is flashed. This is unlikely to happen with this rev since there is no exposure to its pins >.<

The only other deviation I can think of is that we have both bias resistors set at 10k instead of the recommended 12k. That is USBRBIAS and EXRES pins. I am completely unsure of how this will affect performance, but I will be recommending to my hw engineer that we change those to 12k in the next rev.

Whew. Ok, so I am not asking you to debug my hardware for me, but I figured I would post everything that I have found a little odd when reviewing the design because as of right now I am unsure if this is a hw or software issue.

Any initial thoughts on the issue, or ideas for further debugging? I am especially interested in anything that would help prove whether this is hw or sw issue.

Thanks for your help. I will report back with any interesting findings as well.

John Westlake
Posts: 72
Joined: Thu Nov 09, 2017 4:34 am

Re: LAN9514 chip troubleshooting

Tue Jun 19, 2018 9:19 pm

Can you post the schematic of the Section?

Some thoughts:-

1. If the EEprom is fitted (but blank) have you tried to remove it?

2. Is the 25MHz clock good?

As Linux is rather cyptic - in the past when I was fighting such issues I connected the LAN9514 USB Host upstream connections (that would normally go to to the CM3) to a Windows PC where its easier to see whats going on with the USB HUB / LAN... Microchip has the Windows drivers...

In fact for production testing we have a dummy CM3 PCB that routes the designs USB connections to a Windows system where we confirm USB / LAN and WiFi sections are working - one all is good, we then know the PCB is good to go once the CM3 module is fitted.
Last edited by John Westlake on Sat Jun 23, 2018 6:28 am, edited 1 time in total.

link2cory
Posts: 9
Joined: Tue Mar 06, 2018 6:16 pm

Re: LAN9514 chip troubleshooting

Wed Jun 20, 2018 2:42 pm

Thanks for the tips, I tried probing the oscillator and am finding nothing on either end. Wondering if that is just caused by my inability to get a good connection (no test points >.<) or if my chip/oscillator is damaged.

The thing is, that when I booted up just now I checked lsusb and got the following output (ran in quick succession ~1s apart):

Code: Select all

[email protected]:~$ lsusb
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[email protected]:~$ lsusb
Bus 001 Device 000: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[email protected]:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Everything seems to be working perfectly...and then dies suddenly.

I don't see how the device could be temporarily enumerating (not to mention enumerating downstream devices) without a clock. This makes me think that my probing efforts have just been incorrect. Not sure. I will play around with it more and might still try replacing the chip and oscillator.

I did also remove the eeprom which doesn't seem to have made any change (as expected) but it is good to remove as many variables as possible.

I'll see if I can post the schematic. Might have to wait until a bit later.

I wish we had provisioned test points or an external upstream as you suggested. We are both very early in our careers so these are the things you learn as you go :P

Thanks again for your advice.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1309
Joined: Sat Sep 10, 2011 11:43 am

Re: LAN9514 chip troubleshooting

Thu Jun 21, 2018 7:51 am

Where is your LAN_RUN connected? Have you got this wired as recommended by Microchip?
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

link2cory
Posts: 9
Joined: Tue Mar 06, 2018 6:16 pm

Re: LAN9514 chip troubleshooting

Thu Jun 21, 2018 8:37 pm

Gordon,

Thanks for your reply. The nReset pin of the LAN9514 is tied to the 3.3v rail via a 10k resistor.

I am not seeing any specific recommendation from Microchip to do otherwise. All I see in the datasheet is this note:
Note: This pin should be tied high if it is not used.
which is exactly what we are doing. There might be something weird going on since the Pi doesn't actually boot up until the 1.8v rail is powered which I understand needs to happen after the 3.3v rail is powered. So it would seem that the LAN9514 is being brought out of reset before the pi even begins booting, so I can see that potentially being a problem. The weird thing is that it does enumerate briefly which makes me think there is something else at play.

I will try using the pi to control the nReset pin as you have suggested in the past. I haven't messed around with device tree at all yet, but following from your post here: viewtopic.php?t=172619

I should be good to just add these lines:

Code: Select all

[email protected]  { function = "output";  termination = "no_pulling"; }; // LAN_RUN
to pins_cm3

and

Code: Select all

[email protected]_RUN { type = "internal"; number = <9>; }; // LAN_RUN
to pin_defines

in order to accomplish this control using GPIO 9 (SODIMM 29)

I will try this out tomorrow when I am back at my bench.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1829
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: LAN9514 chip troubleshooting

Thu Jun 21, 2018 9:01 pm

From memory, does the datasheet not say that the clock has to be valid before reset is deasserted? How are you clocking the device?

link2cory
Posts: 9
Joined: Tue Mar 06, 2018 6:16 pm

Re: LAN9514 chip troubleshooting

Thu Jun 21, 2018 10:14 pm

Phil,

Hmmm, I don't see anything like that in the datasheet: http://ww1.microchip.com/downloads/en/D ... 02306A.pdf

We are using a 25 mHz crystal oscillator with parrallel 33 pF capacitors to ground as in the reference design:
http://ww1.microchip.com/downloads/en/D ... 14_sch.pdf

I understand that some people have set this up to clock from the rpi which seems like a cool measure I would like to try as well, but Microchip actually states that the crystal is the preferred method of clocking.

John Westlake
Posts: 72
Joined: Thu Nov 09, 2017 4:34 am

Re: LAN9514 chip troubleshooting

Fri Jun 22, 2018 2:53 am

Maybe the trouble is with the Reset as mentioned already - I've found that for "First Boot" Reset is not required (if you reboot the Pi you should also reset the LAN9514).

So try disconnecting the LAN Reset line to the CM3 and see if there is any change (leave it pulled-up via the 10K you mentioned)...

Dont worry - if you get truly stuck I can look at the PCB for you FOC - but you would have to post it to the Czech Rep...

If Reset and clock are OK, then I'd look at PSU decoupling and PCB layout around the device - USB and Ethernet (I know your not currently using the Ethernet port) require care with Controlled PCB impedance's - I've seen designs where datalines / clocks crossover the USB differential pairs causing instability when data starts to toggle on these lines.

For USB, Ethernet & HDMI you really want clean unbroken (matched) differential pairs keeping other datalines / clocks well away from them.

Again, dont worry I'm happy to help you out (FOC) with PCB layout recommendations if required...

Depending on your system requirements its also better to operate the LAN9514 from an external Crystal (as you have done) then from a clock generated from the CM3 SoC - the SoC Clock Gen block has very high data correlated Jitter (Phase noise). For most systems this is workable - but this Jitter does eat into the total "USB" Jitter tolerance margin.

If your not budget limited, then best stay with the Crystal - we pay like US$0.14 for the Crystal so its not even worth considering cost reduction here...

link2cory
Posts: 9
Joined: Tue Mar 06, 2018 6:16 pm

Re: LAN9514 chip troubleshooting

Fri Jun 22, 2018 8:42 pm

John,

Thanks so much for your kind offer! It looks like I got it fixed though. There was no 1MOhm resistor across the oscillator terminals >.<

I don't see any mention of this requirement in the datasheet, but its there on the reference design so I tried it and everything works just fine now!

Thanks again to everyone for helping me debug!

John Westlake
Posts: 72
Joined: Thu Nov 09, 2017 4:34 am

Re: LAN9514 chip troubleshooting

Sun Jun 24, 2018 5:47 am

Great its now working :)

More then happy to give a quick check of your schematics next time round... I'm retired here in the Czech Rep. and bored - so happy to keep dabbling... :)

I've been battling thermal issues with the CM3, so if you plan to use the CM3 heavily loaded you really need to take care with cooling... we are on our third design revision to help keep things cool - its surprising how much heat this little module can put out...

IMO, RPi should add a section on cooling on the Datasheet so more attention is paid to the issue, basically the module is becomes unusable without extra cooling.

We are using Volumio Audio player and this is not really that CPU intensive, but VERY rapidly hits thermal throttling without extra heatsinking.

Return to “Compute Module”

Who is online

Users browsing this forum: No registered users and 6 guests