• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 2975 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.

AM3357: EtherCAT PHY link loss reaction time

Kzk
Genius 5785 points
Part Number: AM3357
Other Parts Discussed in Thread: DP83848I, , TLK110

Hello,

I'll use AM3357 and two DP83848I (or K). I read the Beckhoff application note (PHY Selection Guide) to check connection about "pr1_mii0_rxlink" and "pr1_mii1_rxlink" signals.

http://processors.wiki.ti.com/index.php/FAQ_Sitara_Industrial#Can_we_use_PHY_for_EtherCAT_which_does_not_provide_high_speed_output_indication.3F

The application note has the following description. In order to meet EtherCAT standard, is it mandatory that PHY link loss reaction time is faster than 15 us?

Requirements to Ethernet PHYs used for EtherCAT:
· PHY link loss reaction time (link loss to link signal / LED output change) has to be faster than 15 us to
Enable redundancy operation (2).

(2) This can either be achieved by a PHY with such link loss reaction time or by activating Enhanced link detection if
PHY asserts RX_ER both inside and outside of frames of each invalid symbol. Enhanced link detection required proper
PHY address configuration.

In the table below, there is a descritption of DP83848, but the link loss reaction time is 250 us > 15 us. In order to satisfy EtherCAT standard, I think I should connect pr1_mii1_rxlink and pr1_mii0_rxlink to DP83848 LED_LINK or LED_SPEED. Is my understanding correct? Please give me some advice.

Table 3: Example Ethernet PHY estimated to fulfill EtherCAT requirements
- Link loss reaction time: 250 us
- Enhanced Link Detection: required

Regards,
Kazu

  • 0
    TI__Guru**** 393215 points
    Hi,

    The EtherCAT experts have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Genius 5785 points

    Hello,

    I'm waiting for an answer from EtherCAT experts. Please help me.

    Regards,

    Kazu

  • 0 in reply to Kzk
    TI__Guru**** 393215 points
    I have escalated the request.
  • 0 in reply to Biser Gatchev-XID
    TI__Mastermind 39310 points

    Hi Kazu, your understanding is correct, in order to achieve EtherCAT fast detection requirements, with DP83848, you need to enable "Enhanced Link Detection".

    Below a similar thread for your reference:  DP83848, TLK105/TLK106, TLK110 - Ethercat supporting  

    Thank you,

    Paula

  • 0 in reply to Paula Carrillo
    Genius 5785 points

    Hi Paula,

    Thank you for your help!

    Regards,

    Kazu

  • 0 in reply to Kzk
    Genius 5785 points

    Hi Paula,

    Can I have one more question? I posted to Ethernet forum, but I could not get an information about actual link down time for DP83848 with Enhanced Link Detection.
    e2e.ti.com/.../2133823

    Anyway, could you tell me the method for enabling Enhanced Link Detection to each PHY?

    - DP83848: Connect PHY LED pin to ESC(AM3357).

    - TLK110: Connect PHY LED pin to ESC(AM3357). In addition, enable Fast Link Down by SWSCR3(bit 3 and 0) control.

    I'm not sure that DP83848 supports Enhanced Link Detection even though it doesn't support Fast Link Down functionality of TLK110. Please help me.

    Regards,
    Kazu

  • 0 in reply to Kzk
    TI__Mastermind 39310 points
    Hi Kazu, I don't know the answer, but I will pass this information request to a colleague who is more familiar with different PHYs and EtherCAT. He might know.
    thank you,
    Paula
  • 0 in reply to Paula Carrillo
    Genius 5785 points

    Hi Paula,

    I appreciate your kind support. I wait for the answer from you and your colleague. Also, which one do you recommend to connect AM3357? It means LED_SPEED or LED_LINK of DP83848. Thank you.

    Regards,
    Kazu

  • 0 in reply to Kzk
    TI__Mastermind 39310 points

    Kazu, I checked with my colleague, he suggested another E2E thread with useful information about DP83848. E2E Debug DP83848

    I am afraid in my team we don't have the expertize to help you much deeper. I will try to move this query to another forum for better PHY support.

    thank you,

    Paula

  • 0 in reply to Paula Carrillo
    Genius 5785 points

    Hi Paula,

    Thank you anyway. It seems that there is little information on how to implement Enhanced Link Detection and its result in AM3357 and DP83848.

    Regards,

    Kazu

  • 0 in reply to Kzk
    TI__Mastermind 39310 points

    Hi Kazu, Wiki information for PRU MDIO INIT (which includes some details on Enhanced Link Detection) was recently updated. I hope this helps.

    thank you,

    Paula

  • 0 in reply to Paula Carrillo
    Genius 5785 points

    Hi Paula,

    I appreciate your information. By the way, BECKHOFF PHY Selection Guide describes PHY link loss reaction time (<15us) to meet the EtherCAT standard.

    Requirements to Ethernet PHYs used for EtherCAT:
    · PHY link loss reaction time (link loss to link signal / LED output change) has to be faster than 15 us to
    Enable redundancy operation (2).

    Do you know whether it's mandatory or optional for EtherCAT standard? Please let me know if there is any information on this.

    Regards,
    Kazu

  • 0 in reply to Kzk
    TI__Mastermind 39310 points

    Hi Kazu, I think this would be a good question for ETG forum.. my understanding is that for supporting cable redundancy it is mandatory to have Fast Link Loss Detection (FLD). But I am not sure if cable redundancy is indeed mandatory. Another option (no recommended by us) could be to use Enhanced Link Drop (ELD), instead of FLD. In any case, please check with the ETG experts.

    thank you,

    Paula

  • 0 in reply to Paula Carrillo
    Genius 5785 points

    Hi Paula,

    I understand. I am grateful for your support.

    Regards,

    Kazu

  • 0 in reply to Kzk
    Intellectual 510 points
    Hi Kazu,
    Did you find any solution for implementing Enhanced Link detection in DP83848 for AM335x EtherCAT application?

    regards
    Mohit
  • 0
    TI__Mastermind 39310 points

    Hi Kazu, your understanding is correct. Please check  PRU ICSS EtherCAT firmware API guide for more details. 

    "The setting of Link polarity parameters link0pol and link1pol are determined by MDIOLINK Register when enhanced link detection is enabled.

    MDIOLINK Register is updated after a read of the Generic Status Register of a PHY. Typically the bit is set if the PHY with the corresponding address has link and the PHY acknowledges the read transaction. The bit is reset if the PHY indicates it does not have link or fails to acknowledge the read transaction. Writes to the register have no effect. In addition, the status of the two PHYs specified in the MDIOUSERPHYSELn registers can be determined using the MLINK input pins. This is determined by the LINKSEL bit in the MDIOUSERPHYSELn register.

    The LINKSEL (Link status determination select) bit in MDIOUSERPHYSELn register determines link status using the MLINK pin by setting to 1. Default value is 0 which implies that the link status is determined by the MDIO state machine.

    pr1_mii0_rxlink/pr1_mii1_rxlink pin of PRU-ICSS, which connects to PHY LED_LINK/LED_SPEED pin is connected as MLINK signal to MDIO and in enhanced link detection mode MDIO directly uses MLINK signal to detect the link status from PHY. MDIO state machine based detection is very slow - slow serial link for messaging from MDIO controller to PHYs - this typically takes around 200-250us for PHYs. MLINK/mii_rxlink detection as fast as PHY can toggle this link – with special settings TI PHYs can detect link within 10us, depending on the PHY strap settings link polarity will be different for different boards and needs to adjusted per board by reading MDIOLINK register, also insure to set PHY LED_LINK/LED_SPEED mode as 'LINK_OK' in stead of 'RX/TX Activity' to prevent link detection failure from RX/TX activity."

    thank you,

    Paula