• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 36 subscribers
  • Views 90 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.

Original question:

AM2634-Q1: AM263x EtherCAT Slave Going to Timeout After Few Minutes (TwinCAT 3.1)

AM2634: AM263x EtherCAT Feature Variants

George Kouretas
Prodigy 20 points

Part Number: AM2634

Hello,

Our team is currently developing a custom control board with the AM2634 as the central MCU. We plan on using EtherCAT as the central means of industrial communication. During bringup of the new board, I noticed that the EtherCAT eFuse check for it being an EtherCAT device was "failing" (via this API call: https://github.com/TexasInstruments/ind-comms-sdk/blob/df30fffd3ba9cdb7f88ce683f299aae891a056f0/examples/industrial_comms/ethercat_slave_beckhoff_ssc_demo/am263x-cc/tiescsoc.c#L107). After a bit more digging, I found that this was due to us using a "D" feature MCU (full PN: AM2634CODFHAZCZR) instead of the "M" feature (or one that has EtherCAT HW Accelerator support).

 

We understand that we do need the "M" feature for this check to be happy (we noted that the control-card has this variant, and even performed an MCU swap on our custom board which resolved this check).

The main question I have is what exactly this HW accelerator is and why it would be necessary, as I did confirm that we technically can run the EtherCAT stack and detect the device with an EtherCAT master, so it doesn't appear that it the "non-EtherCAT device" won't work at all. My assumption is that the difference is primarily performance based (per https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1616701/am2634-q1-am263x-ethercat-slave-going-to-timeout-after-few-minutes-twincat-3-1?tisearch=e2e-sitesearch&keymatch=TMDSCNCD263) - we have not tested functionality beyond the ability to detect the device and enter PREOP mode.

  • +1
    TI__Prodigy 672 points

    Hello George, 

    As our expert is out for the week, let me attempt to address your question as shown below.

    - EtherCAT protocol is supported via PRU-ICSS subsystem in AM263x device. 

    - Only the variants with feature letter "E", "F", "L" and "M" in part number are enabled to support EtherCAT. 

    - The difference is not performance based. The issue related to the thread you referred to is that "XAM26 material is pre-production so it is not guaranteed to be configured to DS specifications- in this case EtherCAT was not disabled as it will be for production 'K' devices."

    Thanks. 

    BRs, 

    Michael Wang 

  • +1
    TI__Mastermind 39373 points

    Hi George,

    To add some more detail to Michael's response regarding what the "EtherCAT HW Accelerator" actually is:

    EtherCAT Subdevice implementation on AM263x requires the PRU-ICSS subsystem to act as the EtherCAT processing unit — the "HW accelerator" terminology refers to this PRU-ICSS capability being enabled and configured for EtherCAT Subdevice operation via firmware 2. The "D" variant has one PRU-ICSS instance with MII enabled, which supports standard Ethernet, EtherNet/IP, and Profinet — but EtherCAT is explicitly not supported on this variant 3.

    Why it appeared to "work" on the D variant: The fact that you could detect the device and enter PREOP mode on the "D" part does not mean it is a supported or reliable configuration. The eFuse check exists precisely to gate this — running EtherCAT on a variant without the proper hardware enablement is outside the validated and supported configuration. As Michael noted, the thread you referenced involved pre-production silicon where EtherCAT wasn't yet properly disabled on non-EtherCAT variants, which is not representative of production behavior.

    Regarding the "M" vs "L" or "E" choice: Since you're already targeting the "M" variant, note that "M" includes both the EtherCAT HW accelerator and the pre-integrated commercial stack (provided via TI's partner Kunbus). If you only need the EtherCAT hardware capability and plan to use the open-source Beckhoff SSC stack (which requires ETG membership), the "L" or "E" variants would also be sufficient and may offer cost savings 4. The difference between E/L and F/M is the pre-integrated stack inclusion, not the hardware.

    Bottom line: You must use an E, F, L, or M variant for a supported EtherCAT implementation. The "D" variant lacks the necessary PRU-ICSS configuration for EtherCAT, and any partial functionality observed is not guaranteed or supported.

    Resources:

    1. FAQ: AM2634 - What is Pre-integrated TI Commercial Stack
    2. FAQ: AM2634 - What is Pre-integrated TI Commercial Stack
    3. AM2634 - Difference between AM2634COLFHAZCZR and AM2634COMFHAZCZR
    4. AM263x Device Datasheet

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Prodigy 20 points

    Awesome, this is really great and definitely answers my question.

    I was wondering about the pre-integrated stack - I didn't find much information in my initial search when I was looking into it.

    We are using the SSC stack so we definitely do not have an absolute need for the Kunbus stack, but I'd be curious what information exists about it as an alternative to the SSC stack. Also I am curious what is meant by the "inclusion" of the stack (i.e. do we get access to the stack if we buy X number of "M" variants, is functionality gated for the different stack for the other variants, etc.).