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.

AM2434: Support EtherCAT on PRU_ICSSG with RGMII

Part Number: AM2434
Other Parts Discussed in Thread: DP83867E

Hi,

Can AM2434 support EtherCAT and Ethernet/IP on PRU_ICSSG with "RGMII only"?

My customer considers AM2434 with DP83867E (RGMII interface) to implement EterCAT and Ethernet/IP.  But I hear PRU_ICSS supports EtherCAT with MII, not RGMII.  That is why I want to confirm whether "PRU_ICSSG with RGMII only" support EtherCAT and Ethernet/IP.  Please support us.

Thanks and best regards,
M.Hattori.

 

  • (+) [FAQ] AM2434: Is TI EtherCAT solution in the Industrial Communications SDK compatible with RGMI ? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    Summary : EtherCAT SubDevice over RGMII interface is not supported - latency over RGMII is high on the MAC side at 10M/100M and features like odd nibble detection/insertion won't work.

  • Hi Pratheesh,

    I have some additional questions

    #1. For EtherCAT slave, should enable or disable feature like odd nibble detection/insertion?

    #2. Are odd nibble detection/insertion feature in MAC, PRU firmware or PHY? 

    #3. Beside latency is higher with RGMII, from functionality, can AM243x industry SDK EtherCAT slave example work in RGMII mode.

    #4. Does PRU firmware care if the interface is MII or RGMII? 

  • Hi Tony,

    #1. For EtherCAT slave, should enable or disable feature like odd nibble detection/insertion?

    Bit 1 (Odd-Nibble Detection Disable) needs to be set to 1 to forward odd nibble to PRU firmware and for PRU firmware to insert odd nibble in outgoing packets.

    #2. Are odd nibble detection/insertion feature in MAC, PRU firmware or PHY? 

    It is a combination of all three, and understanding the full flow helps clarify why:

    When an upstream ESC detects a CRC error on a received frame, it forwards that frame downstream with an extra nibble appended after the FCS as an error marker. The receiving ESC must detect this marker, count it as a forwarded CRC error (ESC registers 0x308/0x30A) on the downstream devices.

    • PHY (RX side): The PHY must be configured with its odd-nibble detection disabled (e.g. the relevant "Odd-Nibble Detection Disable" bit set to 1 in the PHY register). This prevents the PHY from internally absorbing the odd nibble condition and instead, it passes it through the MII interface to the ICSSG hardware. If PHY-level detection is left enabled, the PHY silently consumes the error marker and the firmware never sees it, breaking forwarded-error propagation.

    • ICSSG MII-RT hardware: Signals the PRU when an odd nibble condition is present on the received MII data stream.

    • PRU firmware: Acts on that signal to count the forwarded error, and inserts the error nibble marker on the outgoing TX path when forwarding the frame.

    • PHY (TX side): With odd-nibble detection disabled, the PHY transmits the PRU-inserted error nibble as-is without blocking it as a TX fault.

    #3. Beside latency is higher with RGMII, from functionality, can AM243x industry SDK EtherCAT slave example work in RGMII mode.

    For EtherCAT operation, the PRU-ICSSG must operate in MII mode. This is a fundamental requirement of the EtherCAT implementation on AM243x, and RGMII cannot be used.

    #4. Does PRU firmware care if the interface is MII or RGMII? 

    Yes, very much so. The PRU EtherCAT firmware is specifically designed around the MII-RT interface of the ICSSG. EtherCAT SubDevice operation on AM243x/AM64x requires MII mode which is a hardware and firmware architectural requirement, not a software configuration choice.

    Regards,
    Aaron