Lost Ethernet Frames - Collision?

[danh]

Hi Mark,

On my M52235 target, I have a task that sets up a listener on a UDP socket. When a particular sort of frame is received (a broadcast frame from a special utility), then the unit sends a response frame containing various data. This was implemented months ago, and has been working very reliably; the unit always responds very quickly to the broadcast frame.

Recently, and for the first time, I started running two of the targets side by side. At this point I noticed that when the units are both running, I usually don't see the response frames at all. By "usually" I mean that occasionally I do see the response frames; it's always both units, not just one or the other. I have some debug output that shows that the code that sends the response is always getting hit, whether I see the response frames on the network or not.

This is with both units connected to the same ethernet hub. I found that if I connect the units to separate hubs or switches, the problem is not seen. I suspect this is a collision issue. In fact I can see the "Collision" LED on my hub flash briefly each time. Probably when it works it's because one or both of the units lost the ARP entry of the host and had to re-ARP, thus changing the timing of things.

I could add some kind of random delay at the application level. But shouldn't the ethernet driver be handling that, if this is indeed a collision issue?

Thanks,

Dan

[mark]

Hi Dan

Collisions are normal in a (busy) network. They do not represent errors but result in retransmission with a random back-off delay. Collisions should thus not result in any data loss.

However if the Ethernet interface is not configured correctly colliding frames will not be retransmitted and data will be lost.

Are you setting the interface up in auto-negotiation mode? This should always get it right.
If you are using fixed rate (10M or 100M) check also whether you have duplex set. Duplex mode (I think) will not repeat on collisions because it should only be used when connected directly to a switch or a peer. Therefore if using a hub in fixed speed mode try disabling duplex operation to see if it solves the problem.

At the beginning of the uTasker project for the M5223X there was an error in the basic Ethernet/PHY configuration and, although collisions were detected, the EMAC didn't repeat. This resulted in some lost transmissions due to collisions. This was however fixed and the project which identified it also proved that the corrected set up (see change note {1} in M5223x.c) was then reliable. Therefore I expect that it is a setup issue rather than a bug. Hopefully you can confirm this...!

Regards

Mark

[danh]

Hi Mark,

Thanks for your usual fast response.

We are not using auto-negotiation mode because of that bug with the M5223x parts (we have lots of parts that do not have the fix, so we have to work around it). We added some code to periodicallly check for a link, and if not present, try setting up the link at 100m and then 10m. This code actually disables the duplex setting. However, the initial value used to initialize the ethernet driver has duplex enabled; so if the link is detected right away, the manual negotiation stuff doesn't kick in, and the link stays at full duplex. I changed that initial value to disable duplex, and now everything seems fine.

It is unlikely that any user will connect our unit to anything other than a network with multiple other hosts, so I think we should be OK just leaving duplex disabled.

Thanks,

Dan