Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

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.

AM5728: GMAC 802.3x flow control

Part Number: AM5728

Hello, would somebody kindly explain in which case GMAC sends pause frame to the rgmii external port?

There is a section 24.11.4.8.9.2.1 in TRM about receive flow control, but it sais "Receive flow control is triggered (when enabled) when the RX_FLOW_TRIGGER input is asserted." without any details about it. What is a RX_FLOW_TRIGGER and in which case it is asserted?

I've enabled rx and tx flow control and tx flow control is definitely working as it should, because when GMAC is continuously sending frames and it receives a pause frame, it slows down and I can see in the STATS registers that some pause frames have been received. But I can't make a case when GMAC is sending a pause frame to external port. When there's no rx descriptors left it just drops every received packet and increments DMA_OVERRUN counter in stats registers. I'm continuously sending ethernet packets to GMAC external rgmii port via custom designed phy device.

I've found a thread with the same question but for another processor (802.3x Flow Control on the AM335x), the TI employee said that the only way to make GMAC sending pause frames to the external port is to disable RX in CPPI DMA, is that right for the AM5728 processor too? I've tried this and the pause frames were sent as i can see, but that doesn't make a lot of sense because GMAC can't receive packets without CPPI DMA. So is there any way to configure GMAC somehow to make it sending a pause frame in response to packets flood without disabling RX in CPPI DMA?


I'm using only csl from processor-sdk-rtos without any rtos threads.

Regards, Vasilij.

  • The factory team have been notified. They will respond here.
  • Hi,

    The previous post you referenced is correct. The CPSW will honor received Pause frames in a TX context, getting them generated for an RX context is the same as the post and that it will require a SW solution.

    Since you are using a single threaded system one option to manage flow control would be to increase the amount of RX descriptors and place them in DDR rather than the internal CPPI RAM. This will give you a greater depth of RX desc and chance to react to an overflow situation by implementing some kind of FIFO depth scheme allows the CPSW driver to insert a Pause Frame into the TX output queue. This is a recommendation on a possible implementation and has not been verified if it would work. I support Linux and TI has not done this approach for the Linux CPSW driver.

    One thing to note that has pointed out to us is that in the past concerning flow control is that there is not a guarantee that all the devices on the network will honor flow control. So even if the device sends a Pause frame the offending sender may not honor them.

    Best Regards,

    Schuyler

  • Ok, thank you for the reply, I'll look for a software solution. Is this some kind of a hardware bug or something? Why there is no details about it in TRM or errata?
  • Hi ,
    I will look into if this can be added to the documentation.
    Best Regards,
    Schuyler