• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 403 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.

Original question:

TMS570LC4357: EMAC driver must not set TXHDP until EOQ is detected

TMS570LC4357: TMS570LC4357: EMAC driver must not set TXHDP while channel is "active"

Stephen Holstein
Intellectual 290 points
Part Number: TMS570LC4357


In the thread https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/858377/3188037 TI (Iding) asserted that:
    "The transmit channel is inactive when EOQ=1, TXHDP=0, and Ownership=0.  Only when this inactive condition is met, can TXHDP be written with a new head descriptor."

In further testing using this guidance, the hardware still winds up in MACSTATUS ERROR.

I'm now, in addition to the states above, also checking MACSTATUS_IDLE==1 (bit 31) http://www.ti.com/lit/ug/spnu563a/spnu563a.pdf#page=1906

Ensuring MACSTATUS_IDLE==1 appears to work, but again, I'm looking for an authoritative statement as to how the host is to know the channel is INACTIVE before setting a new TXHDP.

The technical reference manual seems to indicate that this MACSTATUS_IDLE should latch to 1 after reset, while characterization demonstrates the bit toggles during EMAC operation.  Is the MACSTATUS_IDLE check required?

  • 0
    TI__Guru* 95265 points

    Hi,

    Sorry the EMAC TX error still happened! I checked EMAC design team and will update you. 

    Regards, Eric 

  • 0 in reply to lding
    TI__Guru* 95265 points

    Hi,

    Here is what I got from design team:

    They do not have to look at MACSTATUS_IDLE==1.

    This could also be a cache coherency issue where the write to the SOP buffer descriptor has not landed in memory before the write to the TXHDP register causes packet operations.  They can rule this out by ensuring that all the write data (descriptors) have landed in memory.  This can usually be done by reading the last buffer descriptor that was written, but they need to ensure all writes have landed in memory (cache writeback operations). 

    They can also preclude other issues by not using the internal buffer descriptor memory – meaning that the buffer descriptors are better off in the same memory with the packet data.  They should always ensure the buffer descriptor data has landed in memory though.

    Regards, Eric