PROCESSOR-SDK-AM64X: EtherCAT Slave link status issues with MCU+ SDK version 08.02

Part Number: PROCESSOR-SDK-AM64X
Other Parts Discussed in Thread: SYSCONFIG, TMDS64GPEVM

Dear TI team,

we're seeing an issue with the EtherCAT slave firmware integrated in MCU+ SDK version 08.02.

If only a single port (usually port 0 "input") is connected to the master, and port 1 ("output") is left unconnected, the EtherCAT network doesn't work. In that case no frames are being returned to the master.

When there are packets being transmitted by the master we can see LEDs on both port 0 and port 1 blinking, even though port 1 is left unconnected. If we briefly connect another device on port 1 and then disconnect port 1, the system behaves as expected, i.e. the port 1 LEDs are off, and frames are being returned on port 0.

We've tried both the ethercat_slave_demo (pre-integrated stack/KUNBUS) as well as the ethercat_slave_beckhoff_ssc_demo (Beckhoff SSC stack) with the same results.

When we replace the firmware used in the ethercat_slave_beckhoff_ssc_demo with firmware from MCU+ SDK 08.00.00.21, the system is working as expected.

For our custom hardware we're using enhancedlink_enable = 0 (MDIO mode). On the EVM we've tested both enhancedlink_enable = 1 (MLINK mode) and = 0 (MDIO mode). In all cases the PRU MDIO registers show "no link" on port 1, just as expected, but the firmware seems to try and send the frames out on port 1 anyway.

Regards,

Dominic

  • Dhaval,

    I provided Dominic the MCU+ SDK 08.03.00 RC1 today.
    Will he see this issue fixed again?

    Regards,
    Bernd

  • Hi,

    ah, good idea. I've downloaded the package already, but we haven't had a chance to look into it yet.

    I'll have my colleague re-run the test with the firmware from the RC1 package next week.

    The documentation says that the EtherCAT firmware is newer (version 6.5.2 vs. 6.5.0), but there's no explanation about the changes. An update of the "Known Issues" and the EtherCAT slave errata would be great.

    MCU+ SDK 08.02 seems to be the first version with slave firmware version 6.x, but the errata document only refers to 5.x versions.

    Regards,

    Dominic

  • Hi,

    we've tested the EtherCAT slave firmware from MCU+ SDK 08.03 RC1, but that didn't fix our issue.

    Regards,

    Dominic

  • Hi
    Are you seeing any issues on TMDS64GPEVM board?

    When using the custom board, what are the PHY addresses? Did you ensure that the correct PHY addresses are configured in SysConfig?

    Regards
    Dhaval Khandla

  • Hello Dhaval,

    yes, the issue appears on the TMDS64GPEVM and on our custom hardware. On our custom hardware the PHYs use addresses 0 and 3. Both are configured in SysConfig.

    We didn't see any issues with previous MCU+ SDK versions, only since 08.02.

    The link detection works just fine if port 1 is plugged and then unplugged. It doesn't work when port 1 was never connected.

    The ICSSG MDIO registers always show the correct link state, i.e. if we start with port 1 disconnected the MDIO registers show no link on port 1. If we connect another device on port 1, the MDIO registers show a link. If we disconnect the additional device the MDIO registers show no link. At that point, the slave behaves as expected, i.e. frames are returned on port 0, not sent out on port 1. This happens on both the EVM and our custom hardware.

    Let me know if you need any more details.

    Regards,

    Dominic

  • Hi

    yes, the issue appears on the TMDS64GPEVM and on our custom hardware

    Have you made any changes to the SDK example? Have you made any hardware modifications the board?

    On our custom hardware the PHYs use addresses 0 and 3. Both are configured in SysConfig.

    Can you share the SysConfig file you are using for this?

    The link detection works just fine if port 1 is plugged and then unplugged. It doesn't work when port 1 was never connected.

    What exactly do you mean by link detection here? Is it MDIO Link status or link status with respect to EtherCAT?

    For ESC DL control, this is expected. Only Port 0 (IN port) is always in "AUTO" mode (in ESC DL Control 0x0100-0x0103 register). So if Port 1 was not connected initially, it will be in "ALWAYS CLOSED" mode.

    Regards
    Dhaval Khandla

  • Hi,

    Have you made any changes to the SDK example? Have you made any hardware modifications the board?

    For our custom hardware we've made several modifications, but for the EVM we're using a vanilla MCU+ SDK 08.02.00.31 and the ethercat_slave_simple_demo built on the commandline:

    gmake -s -C examples/industrial_comms/ethercat_slave_demo/simple/am64x-evm/r5fss0-0_freertos/ti-arm-clang

    For ESC DL control, this is expected. Only Port 0 (IN port) is always in "AUTO" mode (in ESC DL Control 0x0100-0x0103 register). So if Port 1 was not connected initially, it will be in "ALWAYS CLOSED" mode.

    I've digged into this some more, and I believe that's where the problem is.

    • EVM booted with SBL NULL OSPI from MCU+ SDK 08.02
    • ethercat_slave_simple_demo loaded onto R5_0_0 via CCS and running
    • port 0 connected to a master, but master software not yet running. There are a few non-EtherCAT frames from Windows at first, when the link comes up.

    I'm reading the ESC registers via the memory view of R5_1_0 so that I'm not interrupting the slave on R5_0_0:

    0x30090100	00000001	00000000	00000000	00000000	00005211	00000000	00000000	00000000
    

    The ESC DL Control register is 0x0001, the ESC DL Status Register is 0x5211.

    According to DL control, all ports are in Auto mode.

    According to DL status, there's a physical link on port 0, but not on port 1. Communication is established on port 0. Ports 0 and 1 are open.

    According to my understanding, the port 1 should show "closed" in that case, since there's no link, and it is in Auto mode.

    I've tested this with TwinCAT, and TwinCAT is able to establish communication with the slave despite this issue. TwinCAT sends a broadcast write setting register 0x101 to 0x00, putting all ports into Auto mode. This is the default, but with that as an additional init command our own master can talk to the slave as well.

    To me it looks like this is a bug within the TIESC firmware, that is just "hidden" when you're using TwinCAT.

    Regards,

    Dominic

  • Hi

    For ESC DL control, this is expected. Only Port 0 (IN port) is always in "AUTO" mode (in ESC DL Control 0x0100-0x0103 register). So if Port 1 was not connected initially, it will be in "ALWAYS CLOSED" mode.

    Let me correct this statement. This behavior is seen with TwinCAT master.

    From TIESC firmware, we set it to auto for all ports as you rightly observed. It is upto the master to select how to set the control bits for each port.

    Regards
    Dhaval Khandla

  • The issue is that port 1 is open. Shouldn't it be closed, if it is auto, but no link is detected?

  • Maybe it is more obvious with this sequence:

    • EVM booted with SBL NULL OSPI from MCU+ SDK 08.02
    • ethercat_slave_simple_demo loaded onto R5_0_0 via CCS and running
    • NOTHING connected to either of the two ports

    0x30090100	00000001	00000000	00000000	00000000	00005001	00000000	00000000	00000000
    

    --> Both ports 0 and 1 come up as "open", even though they're in auto mode and have no link

    In comparison, this is what I get when following the same steps with MCU+ SDK 08.01:

    0x30090100	00000001	00000000	00000000	00000000	00005501	00000000	00000000	00000000
    

    --> Both ports 0 and 1 come up as "closed"

    Now if you connect another device to port 0, the issue is that in the MCU+ SDK 08.02 case, because port 1 is "open", any frame received on port 0 is forwarded to port 1, where it is lost.

    In the MCU+ SDK 08.01 case (and every other slave we've seen so far, especially the Beckhoff devices), port 1 is "closed", and the frame gets returned on port 0, as it should.

    Again, this seems like an obvious bug in the TIESC firmware, and a regression compared to previous versions.

    Regards,

    Dominic

  • Hi
    We are looking into this. We will provide further response by end of this week.

    Regards

    Dhaval Khandla

  • Hi Dhaval,

    any feedback on this issue? Have you been able to verify our findings?

    Regards,

    Dominic

  • Dominic
    We are able to see the same behavior. I will get back once we have more details.

    Regards
    Dhaval

  • Hi Dhaval,

    any updates on this issue?

    br,

    Armin

  • Hi Dhaval,

    did you check this with Pratheesh already?

    Regards,
    Bernd

  • Hi Armin
    I will provide an update probably by end of this week. Until then, you can use a work-around on master side which Dominic mentioned in one of the replied above.

    Regards
    Dhaval

  • Hi Dhaval,

    any update on this?

    Regards,

    Dominic

  • Hi Dhaval,

    we are still interested on an update on this.

    Regards,

    Armin

  • Armin, Dominic
    Sorry for the delay here. I will provide further response by tomorrow.

    Regards
    Dhaval