CM3L + LAN9514 Problems After Feb. 2017 Raspbian Release

[JinShil]

We are using the CM3L with a LAN9514 connected in what we think is identical to the RPi3 B.

All was working well until the February 2017 Raspbian release. If we use any Raspbian release after January 2017, the USB and Ethernet become flaky (Missing key-presses from USB keyboard. USB mouse that can't move the mouse cursor, Intermittent LAN connectivity, etc...)

We've narrowed down the specific commit to debe2d2

Can anyone shed some light on what that commit did that might be contributing to the problem we're experiencing?

---

Cross-posted from https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=177473

[popcornmix]

Presumably one of:
firmware: leds: Provide a way of changing LED assignments for CM3
firmware: leds: Prevent re-initialisation

@JinShil have you modified dt-blob.dtb to describe the LAN_RUN pin? Can you post any changes made.
@pelwell is it possible this could have affected LAN reset?

[pelwell]

There was a followup commit ("leds: Allow controlled re-initialisation") which is required. Have you tried the most recent firmware to confirm that the problem still exists?

Can you put a 'scope on your LAN_RUN pin to see if it is behaving correctly?

[JinShil]

We tried the latest firmware, but the problem persists.

We have the RESET pin on the LAN9514 tied to 'high' instead of connecting it to the LAN_RUN pin on the SOC.

[pelwell]

I think that's a mistake - the device won't go through a proper reset cycle. We dedicate a whole GPIO pin for this, which is explicitly held low for 150ms. Your device can be reset in the same way if you tie reset to a GPIO and define LAN_RUN accordingly in your dt-blob.bin.

[ghollingworth]

I believe that the problem here is the chip will never come out of reset. The 25MHz clock needs to be running when the nRESET pin goes high. This is why we provide a LAN_RUN output from the processor.

Gordon

[JinShil]

The problem turned out to be a cross-talk problem on our PCB. We had the activity LED pin connected to a FET that ran underneath our USB lines on a different PCB layer. The commit specified in my first post on this issue caused the LED pin to blink on and off creating cross-talk on our USB lines. After removing the FET, everything worked fine. We will need to modify our PCB and hopefully our EEs will take your advice on the LAN_RUN pin as well.

Thank you all for your valuable input.

[bnielsen1965]

@JinShil A related question, we have a CM3 connected to a custom motherboard that has an 9514 chip to provide ethernet and USB ports. The ethernet works but any device we connect to the USB port fails to respond with an ACK when Raspbian sends setup packets over the USB port.

So I was wondering if you had to change anything in your Raspbian setup to get the USB ports on the 9514 to work?

[ghollingworth]

There shouldn't be... Have you got a USB analyser attached downstream of the 9514? Is that how you know it isn't working?

Did you follow the SMSC specification for laying out the PCB traces correctly, is it possible D+ and D- are swapped? Are they definitely starting up in full speed rather than low speed...

[bnielsen1965]

We have a Beagle USB packet analyzer between our custom motherboard that contains the 9514 and a USB flash drive. When the drive is plugged in the Beagle sees a setup packet from the 9514 host but there is never an ACK returned from the flash drive. There are multiple attempts at sending the setup packet but it eventually gives up.

We used the SMSC spec for the PCB layout so I think we should be okay there. We thought the D+ and D- lines might have been swapped so we modded the board to swap the lines but the result is the same. Although it does seem odd that with the lines swapped the Beagle would still see the setup packets.

In the dmesg log I can see where the 9514 is starting up in high-speed...
[ 7.196680] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 7.515733] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[ 7.559228] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 7.606697] hub 1-1:1.0: USB hub found

Odd though, when I plug in the high speed flash drive it tries to connect as low-speed...
[ 8.826731] usb 1-1.2: new low-speed USB device number 4 using dwc_otg
[ 8.976716] usb 1-1.2: device descriptor read/64, error -32

On an RPi3 it connects at high speed, I wonder if this might be a clue to our problem.

EDIT: Actually the D- and D+ were swapped. :) Not sure how but the mod to swap lines was incorrect and lines were not swapped. Anyhow, thanks for the feedback, it helped out a lot.