Interesting problem with 1Gbit, NDK2.0, UDP send, DM648

Update/More info:

I examined the 3PSW register containing the number of TX packets received (TXGOODFRAMES) and it always contains the correct number of (should have been) transmitted frames, even in cases where some were not sent out by the PHY.

I tried slowing down the max rate at which packets can be sent to the EMAC in the send loop, but slowing down the DSP clock and/or building in debug mode, and both of these methods caused missing packet problem to dissappear.

I tried looking at minimum "burst" required at max speed to cause problem (i.e., in loop, send N packets consecutively fast, then sleep, repeat), and missing packets can occur for all N>=2.

So.... I never get problem if EMAC is getting data significantly slower than it is sending it out to PHY (e.g., by sleep in loop, or by slowing down DSP clock), and I never get problem if EMAC is getting data significantly faster than it is sendinig it out to PHY (e.g., when DSP going balls to wall and link is 100Mbits/sec). And I always get proper number of TXGOODFRAMES in EMAC regardless of whether packets were being not sent or not.

This leads me to believe there is timing problem/race condition in FIFO between EMAC and PHY, that only happens when FIFO is not banging on empty or banging on full. The symptom is that the EMAC sees that the packet arrived in the FIFO, but for some reason throws it out instead of sending it to the PHY. Has anyone seen anything like this in the DM648?

Jim

Jim,

This is not unlike the problem I currently have with a DM648 on a custom board.  We are taking in RAW video, processing it, then converting to JPEG for upload via Ethernet TCP sockets with the DM648 as the server. Regularly the sent file fails to arrive at the client.

Thinking that the problem was with our code I have used the NDK benchmark example (NDK 2.0) and send it data with iperf, as described here:  

http://processors.wiki.ti.com/index.php/NDK_benchmarks

The EVM gets a good benchmark, but our board is very slow and regularly crashes before completion.  Putting in a printf in the receive loop of the benchmark testee program we get a low benchmark, but it doesn't crash as often.  100M is worse than 1Gbit.  Resetting the DM648, but not the Phy and reloading it works the same as from a cold boot of the board.  The hardware around the network is identical, same Phy as the EVM, but only one rather than two on the EVM.  The other big difference is that we have a 27MHz clock for the DM648 and the EVM has 33MHz.  What is your hardware setup?  Do you have one or two Phys and which crystal are you using?

We have tested network reliability with a constant ping of the IP address from a PC and our board is regularly unreachable with identical code that runs fine on the EVM.  I think the problem might be either related to the cache not being setup correctly of the different input clock because in our app when the JPEG is enabled the ping test often fails, but with it disabled the ping is quite reliably, no upload running in either case.  I've tried NDK 1.92 and NDK 2.0, both have the same problem.

Any suggestions of thing to try would be much appreciated.

Simon

I can't offer any help, but I'm looking at a similar problem. Perhaps the same issue existed in 1.9x -- this is a problem we've had for >1 year that we have blamed on a bug in our system somewhere.  Recently we've converted to NDK 2.0, and we're revisiting the issue. 

The symptoms are identical: packets go into sendto() and fail to make it out on the wire.