FEC works with crossover, corrupt through hub.

[SeeUnit]

Hello,

I've encountered a very strange problem.  I debugged and tested an Ethernet driver on M54455EVB, FEC0 using a crossover cable to a PC.  This works very well, and there are no issues.

However, when I replace the crossover connection with a switch, everything falls apart.  Transmitted packets (from the EVB) are not received on the PC.  Packets sent from the PC (ie ARP) do get received by the EVB, but they are corrupted.

For example, a transmission from the PC might look like this;

ff ff ff ff ff ff 5c 26  0a 08 c7 5c 08 06 00 01   08 00 06 04 00 01 5c 26  0a 08 c7 5c 0a 01 0a 06   00 00 00 00 00 00 0a 01  0a 0a   

Whereas the receive buffer is a little more like;

ff ff ff ff ff ff ff ffff ff ff ff ff ff ff ffff ff ff ff ff ff ff ffff ff ff ff ff ff ff ffff ff ff ff ff ff ff ffff ff ff ff ff ff ff ffff ff ff ff ff ff ff ffff ff ff ff ff ff 03 00c0 ff ff 57 55 55 55 55a9 aa 6a 55 55 a9 aa 2a00 00 a8 aa aa aa aa 0200 00 00 00 00 00 80 aaaa 02 00 00 00 00 fc ff7f 55 55 01 00 c0 ff ff03 00 c0 ff ff 57 55 5555 55 01 00 80 aa aa 0200 00 00 00 a8 aa 6a 55

 ... and goes on for 600-odd bytes. 

The Rx buffer 'NO' flag (not octet aligned, failed CRC) is set, and the data posted above is copied from the Rx buffer, which implies the error might be in the initialisation, perhaps.

The hubs & switches I have tried all work.  Other devices work with them & all hardware variables have been tested (different switches, hubs & cables).

I really dont know where to start debugging this.  Any ideas?

Kind Regards.

[TomE]

I've had a problem very similar to this a long time ago with 10MHz Ethernet.

Except in this case it could send SHORT packets through an Ethernet Hub, but ones longer than a certain amount would get corrupted. The problem was also unidirectional - it would work one way but not the other way.

In that case the problem was that the crystal oscillator providing the Ethernet clock was out of spec and running slow or fast.

An Ethernet data stream is self-clocking, so in a direct connection it can handle a large frequency error.

But when it goes through a hub or a switch, the data is received by the hub/switch at the transmitter's rate, but then forwarded using the hub/switch's clock. If the transmitter is too fast it will overrun the hub (a switch might cope). If the transmitter is too slow, the hub/switch is forwarding the packet faster than it is arriving and it can underrun.

This may not be your problem, but it is the first thing to check.

There is a spec for the ethernet frequency accuracy, which Google finds as the first hit on "ethernet clock frequency specification":

"The Ethernet specification calls for a reference clock frequency tolerance of maximum 100ppm". It then goes on to say that some devices are as bad as 1000ppm and that devices have to be able to buffer 27 nits to take up the slack.

The other thing to check would be to find out what options have been negotiated with the PC. Maybe it is running 10mHz instead of 100MHz, or is running half-duplex instead of full. That might be why it is working on the PC but not the switch.

Tom

[SeeUnit]

Brilliant, thanks for the advise.