• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 839 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Ethernet not working after link has been down

Gertjan den Hertog
Prodigy 100 points

NDK helloWorld example based program. After the Ethernet link has been down for a moment, and up again, no data seems to be recieved nor transmitted.

May this be related by the QMSS stall (errata), or may there be other reasons?

  • 0
    TI__Intellectual 1880 points

    Gertjan,

    It is unlikely that what you have described is the QMSS stall error. However, to avoid this issue, you should use internal linking RAM (recommended unless you need more than 16K descriptors) or put the descriptors and linking RAM in different locations.

    After the link comes back up, are you able to see any updates in the Ethernet statistics? For example, do you see a change when you send a packet? Any changes indicate that packets are at least getting to the Ethernet switch. Are you seeing any error values in the statistics? Are there any problems indicated in the STATUS register for each of the SGMII modules? 

  • 0 in reply to Derek Brown
    Prodigy 100 points

    Derek, thanks for your reply.

    I do see Ethernet statistics changes after the link is back, so that works. No errors.Ping does not work, and sending data does not work: code runs into EmacSend routine of nimu_eth.c including the QMSS_QPUSH call (pdk_C6678_1_0_0_17), but no changes in the TX statistics after this. In between the SGMII and the IP stack is the problem.

  • 0 in reply to Gertjan den Hertog
    TI__Intellectual 1880 points

    Gertjan,

    Since you are seeing the statistics update, then that means that the packets are getting into the Ethernet switch. Are the packets getting out of the Ethernet Switch?

    If you are not sure, then use can use the following procedure:

     After you encounter the issue, please halt your program so that the you stop sending packets. Also, please do not send any packets to the device.

    Load the attached gel file and run the these two functions:

    • Print_Ethernet_Statistics_A
    • Print_Ethernet_Statistics_B
    Then send one packet.
    Again, run the above 2 functions.
    When a packet enters the Ethernet switch, the RXGOODFRAMES register in the STATSA module should increment. If this value increases after sending the packet, then this confirms that the Ethernet switch is receiving the packets.
    When a packet exits the Ethernet switch, the TXGOODFRAMES register in the STATSB module should increment. If this value increases after sending the packet, then this confirms that the packets are successfully exiting the Ethernet switch, and have not been dropped by the ALE or one of the MAC modules.
    Also, could you please capture all of the output from the gel file and send it back so that I can take a look?
  • 0 in reply to Derek Brown
    Prodigy 100 points

    Got it working after replacing this line in nimu_eth.c

    CSL_CPGMAC_SL_enableExtControl (macPortNum);

    by

    CSL_CPGMAC_SL_disableExtControl (macPortNum);

    Probably related to the board.

  • 0 in reply to Gertjan den Hertog
    TI__Intellectual 1880 points

    Gertjan,

    I am glad to hear that you were able to resolve this issue. From a hardware perspective, this bit does not need to be set if software is going to be setting up the speed and duplexity of the EMAC and SGMII modules. This bit only needs to be set if the EMAC needs to get the speed and duplexity settings from the SGMII module.

    As long as you are setting the EMAC and SGMII modules to the same speed and duplexity, then it is okay to not have the EXT_EN bit set.