"WARNING: TX SGDMA TImeout" and no data sent

[Altera_Forum]

Hy guys, 

I need your help, because trying to implement a SimpleSOcketSever-like NIOSII application. I built a basic NIOSII system including a 10/100/1000 TSE tx-sgda. rx_sgdma and so on. Everithing compiles correctly, at startup atuoneg and link testing succeed. But when I try to open a TCP-IP connection to the board anything happens and a message appear on the console: "WARNING: TX SGDMA Timeout". The same message comes out when I try to send udp packet from the board to the PC. I checked many times the NIOSII sytem configuration but everything seems to be ok. Where does the message come from?  Please, can anyone help me?

[Altera_Forum]

When an Ethernet packet is to be transmitted, the TSE driver places it into the SGDMA buffer and requires the transfer; then it polls the dma status register for completion.  

The timeout error means that the dma status is still busy after a time, namely the data can't be transferred to the TSE. This could be due to a some problem in DMA or TSE module. Did you check if timing is met? Initialization and autonegotiation can complete regularly, because dma is not involved as long as you don't send or receive packets.

[Altera_Forum]

Timing seems to be ok.

[Altera_Forum]

Interesting. I am having a similar problem - except that the transmit sgdma never finishes (always busy), and the receive FIFO is never emptied. 

 Have you looked at the 'MAC Configuration Register Space' to see if the FIFO (transmit in your case) is filling up? (You might also find interesting things in those registers as well - a perusal of the options and their values may shed some light on the situation)

[Altera_Forum]

Check that the SGDMA's master (both data and descriptors) are connected to the correct memory, i.e. the memory the driver uses for packets and descriptors. If the SGDMA can't read its descriptor, it will probably lock up.

[Altera_Forum]

--- Quote Start ---  Check that the SGDMA's master (both data and descriptors) are connected to the correct memory, i.e. the memory the driver uses for packets and descriptors. If the SGDMA can't read its descriptor, it will probably lock up.  --- Quote End ---   Thanks DAIXIWEN, I checked again the connection and everything looks fine, descriptor_read and _write Avalon-MM Masters connect to the on chip descriptor memory Avalon-MM slave, m_read avalon Master connects to the altmemddrbridge avalon slave.

[Altera_Forum]

--- Quote Start ---  Interesting. I am having a similar problem - except that the transmit sgdma never finishes (always busy), and the receive FIFO is never emptied.  Have you looked at the 'MAC Configuration Register Space' to see if the FIFO (transmit in your case) is filling up? (You might also find interesting things in those registers as well - a perusal of the options and their values may shed some light on the situation)  --- Quote End ---   Thanks rustycar, I looked at the 'MAC Configuration Register Space, but i don't see any way to check the fifo status.

[Altera_Forum]

At page 4-29 of the TSE user guide you find the address map of all registers. 

Afterward, at page 4-36 there is the description of command config register, which controls the transmission. Read the relevant registers just after you get the timeout error and seek for any anomaly. If you included the statistics counters, you may retrieve some information from them, too.

[Altera_Forum]

Is your descriptor memory exactly called "descriptor_memory" ? The name is hardcoded in the driver and needs to be absolutely the same. 

Otherwise I would suggest to put signaltap probes around the SGDMA to check what it is doing and if it is stuck in an operation.

[Altera_Forum]

--- Quote Start ---  Is your descriptor memory exactly called "descriptor_memory" ? The name is hardcoded in the driver and needs to be absolutely the same. Otherwise I would suggest to put signaltap probes around the SGDMA to check what it is doing and if it is stuck in an operation.  --- Quote End ---   I put Signal Stap around the TX-SGMA but anything seems to move around it. I' mean "ready" on the outuput streaming interface to the TSE is always active but other signals (all the controls signal to csr, descriptor r/w, m_read) are steady, whatever I do. How can it happen?  To stimulate the system I broadcast an UDP packet from the cpu.

[Altera_Forum]

Regarding FIFO:  

 Sorry, you are correct that there is no '# of bytes in FIFO' register or anything nearly so nice. What I did was ping the TSE until the error bit (statistics counter offset 0x2b) went true.  Since you normally need an arp transmit/reply before you can send any packet to a system, I hardcoded the IP level MAC address into the system from which I was pinging so that no ARP was needed. On Linux use 'arp -i <interface> -s <ipaddr> <macaddr>'). I suppose it might be interesting to watch the arp broadcasts and see if they fill up the FIFO...

[Altera_Forum]

hy guys, 

I got a step forward with this issue. "Warning: TX sgdam timeout" came from a mistake I added in the "tse_my_system.c". ANyway my problems didn't disappear at all. Now I can send over the net a packet, but just only one. I can get it on wireshark but te sendto() never exits and, from signal tap, I can see that cpu is countinuosly reading at sgdma-tx csr  DOes anybody have a suggestion?

[Altera_Forum]

What address is it reading and what is the return value from the sgdma? What is it doing on the avalon stream and m_read interfaces at that moment?

[Altera_Forum]

Hi everyone, 

I am getting error as "Tx SGDMA Timeout" Where shall I doubt, what may be the problem?

[Altera_Forum]

Did you read the suggestions in this thread and did you try them?

[Altera_Forum]

My project was working fine, 

but when I am adding SRAM to the project, I am getting error as "Tx SGDMA Timeout"

[Altera_Forum]

Did you read the suggestions in this thread and did you try them?