Ethernet recieve problem

Posted by slandrum

on Oct 15 2008 16:47 PM

I'm having a strange intermittent problem.

I'm making a device that makes heavy use of ethernet. Most of the time the data that I'm receiving looks fine, but once in a while, it looks like a packet that I'm pulling out of the hardware is mis-aligned in the hardware FIFO. This happens very rarely, but once it does happen, everything is out of sync, and I can no longer receive valid communication over the ethernet until I reset the device.

I'm using the LM3S6911. While I use a lot of custom code in my application to talk to most the hardware, for the time being I'm using EthernetPacketGetNonBlocking() from the DriverLib to retrieve data from the hardware.

Has anyone else experienced anything like this with any of the Luminary parts?

Posted by Bobby Bradford

on Oct 15 2008 22:13 PM

Genius9030 points

After taking a quick look at the code, there may be some cases where the trailing CRC bytes are not properly read from the RX FIFO. This would account for the problem you are seeing.

I will raise a support issue to have this checked. I should have more details within a day or so on how you can work around this issue.

--Bobby

Posted by Bobby Bradford

on Oct 16 2008 08:57 AM

Genius9030 points

We have not been able to reproduce this issue here. At this point, my recommendation is for you to send in additional details to support@luminarymicro.com.

It would be useful to include source code, especially all of the code related to reading the packet. Also useful would be a packet trace (using WireShark, for example), highlighting the last known good packet that was received.

--Bobby

Posted by slandrum

on Oct 16 2008 11:47 AM

Mastermind9510 points

One problem has been capturing the failure. In our application, we're typically receiving around 500 UDP packets/second, and the mean time between failures is on the order of 400-800 operating hours/unit.

Since the UDP packets are sent blind, and the failure is only noticed after the fact (and on a network where we are sending similar data to over 100 devices), isolating the packet in question from the send side is problematic. The only reason we are catching it at all right now is because we are sending to a very large number of devices. We never saw this problem when developing and testing on single unit, but started seeing it after scaling up. Of course, when the mean time between failures for a single unit is on the order of weeks, it's not surprising that we never saw the problem.

I don't expect you'll quickly reproduce the problem.