• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 2461 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.

EtherCAT LEDs on AM335x ICE

Jonathan Marrs
Intellectual 555 points
Other Parts Discussed in Thread: TLK110

Hello,

I am trying to understand the implementation of the EtherCAT LEDs on the AM335x ICE. The ETG.1300 EtherCAT Indicator and Labeling Specification shows that there are four LEDs that are part of the EtherCAT specification:  RUN, ERROR, Link, and Activity.  In the specification, it states that the RUN LED and the Link/Activity LEDs are typically controlled by the EtherCAT Slave Controller (ESC), while the ERROR LED is driven by the application controller (processor or microcontroller instead of ESC).

For the AM335x ICE, from what I can tell, the RUN LED is driven by the EtherCAT Slave Sample Code (SSC) stack.  Although this is not the typical approach recommended by ETG.1300, it seems like a standard option, as there is a software switch in the SSC to choose whether the RUN LED will be controlled by the SSC or the ESC. The ERROR LED is also controlled by the SSC, which follows the ETG.1300 recommendation.

So the RUN LED and ERROR LED are clear to me. However, the Link/Activity LEDs are less clear to me. They should be controlled by the ESC, but now that the ESC is emulated in the PRUs, I am not sure if the AM335x PRUs are really controlling the Link/Activity LEDs. It looks like some GPIO pins were designated for controlling the Link/Activity LEDs (ECAT_LED_3 and ECAT_LED_4) via the AM335x, but I cannot tell if these are being driven by the PRUs (Emulated ESC) or instead by the firmware. I do not believe that the SSC supports the Link/Activity LEDs like it does for the RUN LED and the ERROR LED. I also cannot see where the Link/Activity LEDs would be controlled by the some other part of the SDK firmware, such as the application firmware, etc.

The other option for controlling the Link/Activity LEDs besides having them controlled by the ESC is to have them controlled by the PHYs (TLK110). This is not the recommended approach according to ETG.1300, but it still appears to be accetpable. For the AM335x ICE, it looks like the Link/Activity LEDs on the RJ45 connectors are being driven by the PHYs. So it appears that the AM335x ICE has implemented the PHY-controlled Link/Activity LEDs approach, yet has also implemented separate Link/Activity LEDs (next to the RUN LED and ERROR LED) controlled by emulated ESC or some part of the firmware.

I would appreciate some clarification about how the Link/Act LEDs are controlled by the AM335x PRUs/ESC or firmware, if they are being controlled at all. If the Link/Act LEDs are currently not being controlled by the AM335x PRUs/ESC or firmware, are there plans to implement this functionality in the future? I would also like to know if we should implement both sets of the Link/Act LEDs (PHY-controlled and AM335x-controlled) on our own design for an EtherCAT board, or if we could remove one of the implementations for the Link/Act LEDs.

It would be nice if the Link/Act LEDs were controlled by the ESC instead of the PHYs, as recommended in the ETG.1300, but I would like to know what the implementation is right now and if there are plans to implement only one option vs. the other in the future.

Thanks

 

 

  • 0
    TI__Mastermind 44306 points

    Jonathan,

    I assume you refer to EtherCAT firmware as part of IA-SDK 1.0.0.2. In this version the Link/Act LEDs on the board are not controlled at all. The LEDs on the connectors are driven by the TLK110 phy as you can see in the schematics. But as you say correctly this isn't the best option as LED blinking in this case depends on the number of packets arriving and often the human will only see the on state.

    We are planning to provide support for driving the Link/Act LEDs on the board in one of the next EtherCAT firmware releases. It will also be an area where customers might have to do modifications based on overall pin-mux assignments. As we are just using GPIO there could be variations. Obviously customers need to do what is the best match for their hardware and still allows passing the ETG certification process.

    Regards.

  • 0 in reply to Frank Walzer
    Intellectual 720 points

    Are the Link/Activity LEDs supported in the SDK v1.0.0.4?

    In SDK v1.0.03 they are not supported.

  • 0 in reply to Michael Rinker
    TI__Mastermind 48471 points

    Yes - it is supported and activity LEDs are controlled by A8 based on the feedback from EtherCAT firmware

  • 0 in reply to PratheeshGangadhar
    Prodigy 130 points

    *EDIT*

    Ok I think I see some confusion here, and if not please overlook my ignorance....

    Is the RXLINK signal in the PRU supposed to be an input or an output.  It seems like the original post on this topic infers that the RX_LINK signal is an output from the PRU, by statements such as "I would appreciate some clarification about how the Link/Act LEDs are controlled by the AM335x PRUs/ESC or firmware..." 

    Then Frank Walzer infers that the RXLINK signal is actually an input, by responding with " the Link/Act LEDs on the board are not controlled at all. The LEDs on the connectors are driven by the TLK110 phy..."  I understand this point from reviewing the ICE board schematic.  The phy itself pulls the speed link pin low, when it detects said speed, in order to illuminate the LED on the RJ45 connector as well as signal an input low to the PRU, pin V2. 

    Why then does Frank further infer that the RXLINK pin might become an output from the PRU in the future when he says "We are planning to provide support for driving the Link/Act LEDs on the board in one of the next EtherCAT firmware releases."?? 

    The EtherCat firmware API guide seems to fall on the side that prefers the RXLINK pin as an input to the PRU, not an output, when it states "Enhanced link detection**/Redundancy support - connect LED_LINK/LED_SPEED from PHY here"



    So is the RXLINK signal an input or output to the PRU, if it is an input can it be configured to be either active high or active low (ICE board is active low), and why would an RXLINK output from the PRU ever be useful?  Keeping it an input makes sense, in support of the aforementioned fast link detection .

    So then, once someone anwers those questions....here's another what if?.....

    I noticed after reading from Beckoff's website...

    http://infosys.beckhoff.com/english.php?content=../content/1033/ek1122_ek15xx/html/basics_functionality.htm&id=1660

    "The crucial factor for forwarding EtherCAT telegrams is that a link signal is reported only from one slave to the next if both slaves are actually ready for real-time participation in data processing. Specifically, this means that an EtherCAT slave should not open the respective Ethernet port until it is ready to receive and forward an Ethernet frame immediately."

    I was thinking then that if we allow the phy to signal the link speed to the PRU, then wouldn't it be possible for a false signal to occur in certain scenarios?  Lets say the PRU is down on side of the connection...the two phy's are still powered up and they are going to be talking to each other via auto negotiate pulses and thus they will still signal that there is the proper speed link, even though the one slave isn't truly ready for real time action.

    Thanks a lot for any insight I can get on this topic.

  • 0 in reply to Rick Brower
    TI__Mastermind 48471 points

    Hi,

    >Is the RXLINK signal in the PRU supposed to be an input or an output.

    Firmware API guide is correct. It is in an input which is used by PRU-ICSS MDIO to detect fast link indication from PHY (if capable) via LED_LINK/SPEED overriding h/w state m/c which uses slower PHY register polling approach. Either mode (fast mode using RX_LINK, slowmode using MDIO state m/c) can be selected using host (Cortex-A8 for AM335x) side interface

    >I was thinking then that if we allow the phy to signal the link speed to the PRU, then wouldn't it be possible for a false signal to occur in certain scenarios?  Lets say the PRU is down on side of the connection

    I believe ARM side stack has got error handling measures here like PDI WD and PD WD of ESC and take corrective measure for very very rare unlikely scenario of PRU being down...

  • 0 in reply to PratheeshGangadhar
    Prodigy 130 points

    Thanks for the clarification. I don't see the link to mark the question as 'answered? 

  • 0 in reply to PratheeshGangadhar
    Prodigy 130 points

    oh and one more question..is the RXLINK input user configurable for active high and/or active low?  The ICE board has it set up for active low, but just curious for flexibility with design.

  • 0 in reply to Rick Brower
    TI__Mastermind 48471 points

    Yes - you can use it active high/low - just need to indicate the right polarity to firmware.

    http://processors.wiki.ti.com/index.php/AM335x_EtherCAT_firmware_API_guide#bsp_pruss_mdio_init

    • pmdio_params->link0pol: LINK_MII signal polarity of PHY hooked to PRU-ICSS MII0
    • pmdio_params->link1pol: LINK_MII signal polarity of PHY hooked to PRU-ICSS MII1