7
\$\begingroup\$

I have a PCB designed using both 10Mbit and 100Mbit Ethernet, I have produced 100 boards 97% of which work perfectly (both 100Mbit and 10Mbit). On 3% of my boards the 10Mbit operates all the time, but the 100Mbit fails on some interfaces. For example I have two Ethernet ports from my PC, one from the motherboard and a second PCI-X Ethernet card. On the motherboard port all devices operate correctly. On the PCI-X based port 10Mbits works and 100Mbits doesn't. The PCI-X Ethernet device obviously works for the 97% of the devices. If I use a switch between the PCI-X port and my device 100Mbit works all the time.

I'm concerned that I have a problem with my Ethernet interface causing it to be marginal. Has anybody seen this before or could somebody offer some hints of where to look for the problem?

UPDATED

I'm using the Micrel KSZ8041 Ethernet PHY.

When I find a failing PCB it doesn't work with other designs I have which I know are in spec (although thanks this was a good suggestion).

Here are my schematics:

On my failing units I have

  • Removed the ESD protection.
  • Added 1uF on the transformer center tap.
  • Adjusted all the filtering components.
  • Swapped most components between a working unit and a failing unit except the PHY and DSP.

My connector P300 is not an RJ45, instead it is a 2mm through hole header where a custom wire loom connects to an RJ45 on a separate PCB. I have excluded this header and the separate PCB from the equation by wiring directly to P300.

Not sure if it makes a difference but this works with a longer Ethernet cable (5m is okay 0.5m is not).... which points to the matching components/layout. I've reviewed the grounding.

On the inside of the transformer the tx & rx are balanced and on an internal plane between two ground planes (the tx & rx pair are tightly coupled together (9 mils separation) and good spacing between the pairs & other tracks (at least 40 mils). On the outside of the transformer the tx and rx pairs run over a separate chassis gnd plane.

I'm convinced the problem is between the PHY and the outside world (not excluding the PHY). When I probe the rx0 line between the PHY and the DSP a working unit shows only traffic when I ping, but a failing unit has a constant stream of data (presumably idle characters incorrectly received).

I'm currently investigating renting some compliance testing equipment.

\$\endgroup\$
  • 4
    \$\begingroup\$ Adding some further detail, schematics, and specific part numbers would help provide more considered, qualified responses. \$\endgroup\$ – Anindo Ghosh Mar 12 '13 at 6:30
  • 1
    \$\begingroup\$ Consider the possibility that your design and/or the port you connect to is be (slightly) out of spec, which might be no problem when the peer side is well within spec. \$\endgroup\$ – Wouter van Ooijen Mar 12 '13 at 8:11
  • \$\begingroup\$ I am controlling the PHY Linking speed, I have excluded everything but 100 Full duplex from the auto negotiate table. We acheive a link, but data (presumabbly incorrectly received idle characters) is constantly send out of the PHY to the DSP. Could this be a synchronisation failure? \$\endgroup\$ – user20123 Mar 13 '13 at 5:16
  • \$\begingroup\$ You should have enough reputation to post the schematic now, and you can always consider the built-in design tool (CircuitLab) \$\endgroup\$ – clabacchio Mar 13 '13 at 7:51
  • 2
    \$\begingroup\$ You are starting to get into territory where layout matters as much as schematic. But also consider mislabeled/misinstalled passives or marginal magnetics. Can you "move" the problem by trading parts between boards? You might also see if there is $$$ ethernet test gear you could rent to get compliance metrics more detailed than works/doesn't. \$\endgroup\$ – Chris Stratton Mar 13 '13 at 13:46
3
\$\begingroup\$

This is not a complete answer, but it's a good first step.

I recommend checking the PHY's mode switches. It's probably set to auto-negotiate, meaning the PHY will fall back on a slower data rate if the faster one proves marginal. If you can force the faster data rate, it'll be much easier to debug the problem.

\$\endgroup\$
3
\$\begingroup\$

We can only guess from the information you have given. The fact that it works at low frequency but not at high frequency is a clue that somewhere some high frequency issues have not been properly addressed. This may be a systemic problem so that high frequency opreation is marginal and happens to fail 3% of the time. Or, the non-working units could each have a failure that hurts high frequency operation a lot more than low frequency operation.

Given the above, I'd look closely at the terminating resistors, filters on the center taps, decoupling of all the chips envolved, and the general layout including the ground plane and ground currents. Perhaps it is as simple as the terminating resistors didn't get properly soldered on the failed units. Worst case you have something like badly designed ground or even left off a bypass cap or series inductor or filter cap for the center tap of the transmit primary.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.