Strange Ethernet behaviour

[Altera_Forum]

We currently have a a design which is based heavily upon the Cyclone 3 FPGA dev kit. However, at this point it is very difficult to return to the Dev Kit to test the software some am hoping someone has some thoughts on this. 

 Using iNiche i bind and listen to a socket, once this is complete i begin sending data (1300 bytes ish per send) at around 32Mbps. Now here is the problem this only seems to work 50%. I have spent a number of days on this and have added some calls to the TSE registers to allow me to see the tx and rx frame errors.   So if after a restart i check the Tx Frame register i can see errors slowly but reasonably steadily incrementing it will not work. (as in Socket usually connects but no Tx) However, if i check and no Tx Errors exist all is well?   According to the Link activity and Powers up txt (Below) we have 1000Mbit connection and all is well. During good operation i still see a number of Tx Frame errors which is a a concern but it does work.   All ideas welcome.   Cheers Tim   *** Power Up Text *** [tse_mac_init] INFO : TSE MAC 0 found at address 0x10002000 INFO : PHY Marvell 88E1111 found at PHY address 0x12 of MAC Group[0] INFO : PHY[0.0] - Automatically mapped to tse_mac_device[0] INFO : PHY[0.0] - Restart Auto-Negotiation, checking PHY link... INFO : PHY[0.0] - Auto-Negotiation PASSED MARVELL : Mode changed to RGMII/Modified MII to Copper mode MARVELL : Enable RGMII Timing Control MARVELL : PHY reset INFO : PHY[0.0] - Checking link... INFO : PHY[0.0] - Link not yet established, restart auto-negotiation... INFO : PHY[0.0] - Restart Auto-Negotiation, checking PHY link... INFO : PHY[0.0] - Auto-Negotiation PASSED INFO : PHY[0.0] - Link established INFO : PHY[0.0] - Speed = 1000, Duplex = Full OK, x=1, CMD_CONFIG=0x00000000 MAC post-initialization: CMD_CONFIG=0x0400020b [tse_sgdma_read_init] RX descriptor chain desc (1 depth) created IP address of et1 : 192.168.10.82

[Altera_Forum]

What do you mean with "seems to work 50%" ? 

One time it works and the next one it fails or do you expect double the speed you get now?

[Altera_Forum]

Sorry not being very clear there. By 50% i mean that it will work quite happily for an hour or several hours, but once restarted the system may struggle to Ping and the connection is awful. (as in very slow speed and struggles for connection). 

 Another restart and the system seems more than happy again.   Hopefully that makes sense.  Cheers Tim

[Altera_Forum]

Do you have a point to point connection or are you connected to a LAN? 

DHCP or fixed IP?  I don't know if your case could be related to this: Last year I had a problem with iniche+tse: in presence of concurrent tx and rx, some frames were lost. If tx and rx were not overlapped there was no problem. After long investigation, I discovered the problem was in sgdma driver: sometimes rx and tx frames got corrupted because dma data was allocated in the same memory area. I never found if I myself was making some error or if this is an undocumented driver bug: if you use TCP this behaviour is somehow hidden, since TCP would recover the lost frames and you get only a minimal performance loss.  I only needed 100Mbps, so I solved the problem using the opencores mac in sync mode.

[Altera_Forum]

Thanks for you reply and suggestions. 

 The Board is connected via a GBit switch to a test network that has very little traffic. The issue appears to be present when connected directly using a cross-over cable too, so is unlikely to be network related.   We have made some progress today by changing the timing bits in register 20 of the Phy (Marvel as per DevKit). Originally this is set to 0x82 which enables a timing offset in the Phy for both Tx and Rx. By Changing this to 0x02 (process of ellimination) this turns the Rx delay off.   I'm still unsure as to why this corrects the issue (hides), more investigation is needed but at least something positive.   Cheers Tim

[Altera_Forum]

This could be similar to the problem I found and described in the previous post. 

System behaviour changed completely when I added or removed delays. For example the connection worked fine if a hub or switch was inserted between server and client, failed if I connected directly. Same if I artificially delayed tx or rx frames. As I told you, this was related to the concurrence of tx and rx data in sgdma.

[Altera_Forum]

Thanks for you help, We'll have a closer look at the timings around the SGDMA and the Memories to see what is happening there.  

 We do have a couple of timing warnings in the system so maybe clearing these up might reduce the need for the modification to Rx Timing delays.   I have another question though which might well be semi related to these problems. I have found that when a something connects and disconnects rapidly i begin to see the "No free buffers for rx" and this then repeats and eventually crashes the system.   I have looked for this on the forum but not found anything that matches my symptons. Have you seen this or have any ideas. I cannot really see why it keeps requesting RX buffers. Although i do try and send as soon as the connection is made. Perhaps i should have some stable time to ensure it doesnt disconnect on me.   Cheers Tim  

[Altera_Forum]

Yes, I had sometimes your same symptoms with the "No free buffers for rx" messages and crash. 

This happened in the debug phase when my application couldn't store/process all the received data. This was typical in a situation where I had another high priority task that blocked the network task for a sensible amount of time. I think the crash was caused by sgdma which kept on loading incoming data into memory, so generated an overflow. In rare cases I had the same problem when application accepted the first connecion or when the debugger restarted the program after hitting a breakpoint. For these I didn't find an explanation. I never tried if the same problem is triggered by a rapid connect/disconnect.