EtherCAT LEDs on AM335x ICE - AM3x Sitara ARM Processors Forum - Sitara™ ARM®

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

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.