MCF52233: Lost UDP packets

[wyliek]

Hi there everyone

I've been using the M52233DEMO board and running Interniche's Coldfire Lite stack and NicheTask. I have written an application which polls the demo board for GPIO pin levels via UDP. This works fine over a crossover cable between my pc and the demo board. However, when i connect the two to a LAN carrying other traffic, the M52233DEMO board frequently (up to 5 times per minute) does not receive a single UDP packet. By not receiving, I mean that I can find no trace of the packet even being received by the FEC. I called fec_stats() after a couple of missed packets which showed that I had a single RxBD overrun error and a Non octet align error. I don't think these relate to the original problem though.

(The UDP packets I send to the device contain less than 30 bytes of data each)

The fact that packets are not received, only when other network traffic is present, leads me to believe that It may be due to buffer overflow of some sort. Could anyone suggest a course of action to suss out and solve the problem?

My first thoughts would be to fiddle with the values of:

NUMLILBUFS

NUMBIGBUFS

NUM_RXBDS

Would this be a good course of action, and are there any constraints I should consider before going this way?

Thanks

Kyle

[mjbcswitzerland]

Kyle

It may be that the frames are not arriving at all to your board (if possible, repeat the tests using a hub connected to the board and sniffer (like Ethereal) to see whether the frames are really there.

Switches in the network often use some form of store and forward mechanism and if you are sending lots of UDP frames there are often buffer overflows in them. This shows that short fast UDP frames without a reliable protocol on top can be quite unreliable even in local networks!!

Also take a look at the uTasker project since it allows you to run the M5223X code on a PC in a simulator where over flows are very unlikely - it is useful for detecting problems releated to the hardware or of purely software nature.

Regards

Mark

www.uTasker.com