Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

"WARNING: TX SGDMA TImeout" and no data sent

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?

16 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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...