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.

PRU-ICSS-INDUSTRIAL-SW: Correct Implementation of an EtherCAT single port configuration with enhanced link detection enabled with the AM3357 and DP83826

Part Number: PRU-ICSS-INDUSTRIAL-SW
Other Parts Discussed in Thread: AM3357

In our implementation we leverage a single port (Port 0) of the RMII interface and MDIO of the AM3357 to communicate via EtherCAT through the PRU-ICSS and a DP83826 PHY. To do so, we bootstrap the DP83826 with LED1 output on pin 31 as per the pin strap recommendations in How and Why to Use the DP83826 for EtherCAT® Applications (Rev. C). We also use some of the pinmux-able PR1_MII1_* pins for other purposes, mainly configured as GPIOs.

When implementing the polarity of link0 and link1 through the 'TIESC_LINK0_POL' and 'TIESC_LINK1_POL' macros (see Ethernet PHY Configuration Using MDIO for Industrial Applications) in the PRU EtherCAT Slave application I'm noticing that I can only select 'TIESC_LINK_POL_ACTIVE_HIGH' for link1 even though the pinmux of pin GPMC_BEn1 is muxxed to GPIO1_28. If I use 'TIESC_LINK_POL_ACTIVE_LOW' the slave is no longer detected via the Acontis EC-Engineer application.  Would you be able to help me understand why this is the case? I've tried disabling enhanced link detection for port 1 via the 'MDIO_enableLinkInterrupt()' routine which sets bit 7 (LINKSEL) of the MDIOUSERPHYSEL1 register (offset 0x8C) to 0 to fall back to the MDIO state machine as recommended the previous link. This results in the same behavior: an undetectable slave.

From a general sense, what's the appropriate way to configure the PRU-ICSS EtherCAT slave firmware so that I can operate with enhanced link detection only on MII port 0?

Thanks in advance!

  • Hello Ryan,

    A  correction, PRU-ICSS does not support RMII interface for EtherCAT. Only MII is supported.

    This results in the same behavior: an undetectable slave
    • Can you share the MDIOAlive and MDIOLink register values when MDIO_enableLinkInterrupt is enabled and disabled.

    Regards,

    Aaron

  • Thanks for the correction. With enhanced link enabled, I'm reading 0x00000002 and 0x00000002 in the MDIOALIVE and MDIOLINK registers respectively. With enhanced link disabled, I'm reading the same. For some reason, I can't get CCS to read the MDIO registers via the A8 addresses so I had to use the global PRU addresses of 0x4A332408 and 0x4A33240C. 0x00000002 aligns with our bootstrapped PHY address of 0x1.

    While investigating the registers you pointed out above, I did find a hardware error where the rxlink line was constantly being pulled low. That was corrected, however, I'm still seeing the same behavior where setting a polarity of LOW on link 1 while in enhanced mode prevents masters from detecting the slave on link 0.

    My assumption is that the firmware on the PRU-ICSS thinks that a link is present on the 2nd MDIO instance with a low polarity since the line is not pinmuxed out to the pad. Since there isn't a link, this is somehow impeding the firmware's ability to service link 0. Can you confirm this behavior?

    Regardless, it seems like the answer is to disable enhanced link detection on any unused MDIO instances by appropriately setting bit 7 of the MDIOUSERPHYSELx registers.

  • Further investigation is showing that even with disabled enhanced link detection on the unused MDIO, the slave on instance 0 cannot be detected with a polarity of LOW.

  • Hi Ryan,

    You will need to set the TIESC_LINK_POL of the unused port to TIESC_LINK_POL_ACTIVE_HIGH as link state on the port will be zero (bit clear) and this will make the firmware to configure the Port State correctly.

    With enhanced link enabled, I'm reading 0x00000002 and 0x00000002 in the MDIOALIVE and MDIOLINK registers respectively.
    •  I believe MDIOLINK should be 0x00000000 when the link is up since DP83826 phy has signal polarity of active low (by default), and MDIOLINK 0x00000002 when link is down.

    Regards,

    Aaron