This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Beagle Bone Ethernet PHY problem

Hi,

  In my testing on am335x beagle bone, I've met an issue related to Ethernet . The Ethernet PHY can’t work normally at times if I pull out the cable for more than 30s. After reconnecting the net cable, It doesn't work any more. I've check the "dmesg", nothing happened after "PHY: 0:00 - Link is Down ". Then if I pull out and reconnect again, it is possible to work again but not succeed every time.  

  But this issue never happen when I tried to connect the beagle bone to switch but not router. And When connected to the router, using cross-line instead of direct-line can help to solve the problem in larger extent. 

  Does anybody met this before or has any idea what's the reason?

  Thanks.

  Steven

  • I don't know if it's relevant or not, but we manufacture a variety of Ethernet devices, both from our own design as well as using plug-on modules from various manufacturers.  We've noticed that certain switch/router devices from certain equipment manufacturers can be more sensitive to connecting to some devices: it appears to be the physical layers adversely interacting.  Sometimes during production test we'll test 100 units on a certain switch that we normally use, but maybe 1 or 2 won't get link reliably.  But if we use a different switch then all 100 devices are bulletproof.  So for us we see a difference between Linksys, Cisco, Dell, DLink etc. devices.  Sometimes this also seems to extend to sensitivity to the cables involved, but seemingly to a much lesser extent than the switch itself.

    When you say you are using a switch and a router, are they from different companies?  That alone (with all other variables such as power and grounding etc.) could be the origin of the issue: if you have a certain device that works reliably 100% of the time, I'd suggest sticking with that device during development to avoid chasing software ghosts when the hardware is potentially to blame.

    Darrin