• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 357 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.

TMS570LS3137-EP: TMS570LS3137-EP: EMAC pin configuration Eval board

Subash Sundaresan1
Intellectual 560 points
Part Number: TMS570LS3137-EP
Other Parts Discussed in Thread: TMS570LS3137, DP83640, HALCOGEN, TMS570LC4357

We are implementing EMAC (MII mode, full duplex)  in TMS570ls3137 using Eval board, when we look at Eval board schematic (TMS570LS31x HDK), it has been mentioned that "Add a 2.2K ohms pull-up resistor to CRS/CRS_DV signal", however in TRM (SPNU499C–March 2018) it has been mentioned that "MII_CRS In full-duplex operation, the MII_CRS pin should be held low." 

The above contradicting statements leads to confusion, could you please guide us what to do for MII mode full duplex mode?

  • 0
    TI__Guru**** 191066 points

    Hi,

      If you are going to operate in full-duplex mode then the CRS is not meaningful. Please see below from Wikipedia on MII interface. So if you are in full-duplex mode then you can tie MII_CRS low. 

    The CRS and COL signals are asynchronous to the receive clock, and are only meaningful in half-duplex mode. Carrier sense is high when transmitting, receiving, or the medium is otherwise sensed as being in use. If a collision is detected, COL also goes high while the collision persists.

    In addition, the MAC may weakly pull-up the COL signal, allowing the combination of COL high with CRS low (which a PHY will never produce) to serve as indication of an absent/disconnected PHY.

  • 0
    TI__Guru**** 191066 points

    Hi,

      If you are going to operate in full-duplex mode then the CRS is not meaningful. Please see below from Wikipedia on MII interface. 

    The CRS and COL signals are asynchronous to the receive clock, and are only meaningful in half-duplex mode. Carrier sense is high when transmitting, receiving, or the medium is otherwise sensed as being in use. If a collision is detected, COL also goes high while the collision persists.

    In addition, the MAC may weakly pull-up the COL signal, allowing the combination of COL high with CRS low (which a PHY will never produce) to serve as indication of an absent/disconnected PHY.

  • 0 in reply to Charles Tsai
    Intellectual 560 points

    For testing purpose we are using HALCoGen code and we have enabled Dp83640 loopback. We have selected MII mode with full duplex mode. we receiving the data however we have observed data corruption.

    Example:

     SRC MAC address: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

     DST MAC address: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

     Len :                         0x00, 0x80

    when we send data as 0x02, 0x02,...0x02 we are receiving  0x82, 0x82,...0x82 

    when we send data as 0x22, 0x22,...0x22 we are receiving  0xAA, 0xAA,...0xAA

    when we send data as 0x03, 0x03,...0x03 we are receiving  0xC3, 0xC3,...0xC3  

    when we send data as 0x33, 0x33,...0x33 we are receiving  0xFF, 0xFF,...0xFF

    Do you have any clue for this issue?

  • 0 in reply to Subash Sundaresan1
    TI__Guru**** 191066 points

    Hi,

      I don't know what went wrong. Did you run the HalcoGen example as is or you modified it? Can you double check all the steps mentioned in the example are followed?

    I found this post that may also help you debug. 

    https://e2e.ti.com/support/microcontrollers/hercules-safety-microcontrollers-group/hercules/f/hercules-safety-microcontrollers-forum/686161/tms570ls3137-emac-module-is-initialized-but-no-packets-are-sent/2529181?tisearch=e2e-sitesearch&keymatch=emac%252520loopback%252520mode#2529181

  • 0 in reply to Charles Tsai
    Intellectual 560 points

    We haven't modified the HalcoGen code, we have following questions as well,

    1. In the above above it has been mentioned that "the descriptor written to TXnHDP should be swizzled". If yes then,  the "uint32 EMACSwizzleData(uint32 word)" function given only for "tms570lc4357" build, not for "tms570ls3137".

    2. Eval board schematic (TMS570LS31x HDK) suggested "Add a 2.2K ohms pull-down resistors to RXD_2 and RXD_3 signals." is it really required and what is the significance.

  • 0 in reply to Subash Sundaresan1
    TI__Guru**** 191066 points

    HI,

    Subash Sundaresan1 said:
    1. In the above above it has been mentioned that "the descriptor written to TXnHDP should be swizzled". If yes then,  the "uint32 EMACSwizzleData(uint32 word)" function given only for "tms570lc4357" build, not for "tms570ls3137".

    The swizzle requirement is only applicable to the TM4CLC4357, not TMS570LS3137. 

    Subash Sundaresan1 said:
    2. Eval board schematic (TMS570LS31x HDK) suggested "Add a 2.2K ohms pull-down resistors to RXD_2 and RXD_3 signals." is it really required and what is the significance.

    I see that comment too. The EVM board doesn't have the pullup implemented even though the footnote recommended it. However, at this moment, I doubt it is the root cause of what you see. Although I don't have the EVM board to verify the example, the HalcoGen example has been available for quite a while as well as the EVM board. Searching the forum archive, I haven't come across anyone reporting the loopback example showing the behavior as you reported. 

    Can you also try the LwIP webserver example in http://software-dl.ti.com/hercules/hercules_docs/latest/hercules/Examples/index.html