• State TI Thinks Resolved
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 81 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: EtherCAT PDO Configuration

Sapna N
Prodigy 10 points

Part Number: AM6442

Hello,

I am trying to add new PDOs to the existing ethercat subdevice beckhoff ssc demo. I added the required data to the tiescappl.xlsx and created slave source files through the SSC tool.

I then flashed the generated xml file to the EEPROM through the EEPROM programmer. I set up a TwinCAT project using instructions from this link:
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am64x/2026_00_00_06/docs/api_guide_am64x/ETHERCAT_SUBDEVICE_DEMO_TWINCAT.html


None of the changes I made were reflected. The TwinCAT threw an error:

"State change aborted (requested SAFEOP, back to PREOP)
"PREOP to SAFEOP failed. Error 'check device state for SAFEOP. AL Status '0x0012' read and '0x004' expected. AL Status Code '0x001e - Invalid SM IN Cfg'

I then put the generated TIESC.xml file in the TwinCAT/3.1/Config/Io/EtherCAT folder. Only then the TwinCAT showed the updated PDO list and the application ran successfully. 

I have the following questions:
1. The TwinCAT is supposed to read the EEPROM of the device to get the slave details. Why did it not happen? I created another project, restarted the TwinCAT application but still it did not fetch the details.
The new details were fetched without having any reference to the xml file in the TwinCAT folder only if device info was changed. What is the correct behaviour?
2. Is editing the tiescappl.xlsx and generating slave stack source files from the SSC tool the only way to perform this operation? What is the alternate method to add/modify the PDOs without involvement of the SSC tool?

Kindly guide me through the process.

SN 

  • 0
    TI__Genius 14045 points

    Hi Sapna,

    Sapna N said:
    1. The TwinCAT is supposed to read the EEPROM of the device to get the slave details. Why did it not happen? I created another project, restarted the TwinCAT application but still it did not fetch the details.

    TwinCAT does not treat the live SDevice EEPROM as the primary source for PDO/SM configuration during engineering. The flow is:

    1. When TwinCAT scans a SDevice, it reads only the identification information from the SII (EEPROM) — Vendor ID, Product Code, and Revision Number (plus serial number).
    2. It then looks up its local ESI cache (TwinCAT/3.1/Config/Io/EtherCAT) for an XML entry whose Vendor ID/Product Code/Revision Number matches.
    3. If a match is found, TwinCAT trusts that cached ESI file for the PDO list, Sync Manager assignment, CoE object dictionary structure, etc. It does not re-derive the PDOs from the SM PDO-assignment area of the live EEPROM each time, even though that data is technically present in the EEPROM.
    4. Only if no matching ESI is found (e.g., because you changed the Revision Number, so the previously cached description no longer matches) does TwinCAT fall back to building a "generic"/scanned configuration directly from what it can read from the EEPROM at that moment.
    This is exactly why:
    • Simply flashing the new TIESC.xml-derived EEPROM contents did nothing as the old cached ESI (from your first install) still matched on Vendor/Product/Revision, so TwinCAT kept using the stale cached PDO definitions.
    • New device creation/restarting TwinCAT didn't help either, because the stale ESI was still sitting in the ESI folder and still matched.
    • It only worked when you dropped the new TIESC.xml into the ESI folder. That's the correct, supported way to make TwinCAT recognize new PDOs.
    • In your case, 0x001e - Invalid SM IN CFG error was thrown by TwinCAT as the PDO lengths had a mismatch with respect to the configuration in the application (SMLength != nPdInputSize, where SMLength is the length read from the ESI and nPdInputSize is the value configured in the SDevice application).
    Correct behavior / best practice:
    • Anytime you regenerate the ESI (TIESC.xml) with new/changed PDOs, always copy it into TwinCAT/3.1/Config/Io/EtherCAT (replacing/adding alongside the old one).
    • Make sure you re-launch the TwinCAT GUI so that the device description table to TwinCAT is refreshed and it's able to read the newly added ESI file.
    Sapna N said:
    2. Is editing the tiescappl.xlsx and generating slave stack source files from the SSC tool the only way to perform this operation? What is the alternate method to add/modify the PDOs without involvement of the SSC tool?

    For pure re-mapping of existing CoE objects, you can skip the SSC tool and just edit SDOs/ESI directly. For adding brand-new PDOs/data items, tiescappl.xlsx + SSC tool regeneration of the SDevice stack source is the required and only supported path (in my knowledge), since it keeps firmware and ESI in sync.

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 10 points

    Hi Aaron,

    Thanks for the reply.


    We would like to understand how the Industrial Communications SDK (EtherCAT SubDevice Beckhoff SSC demo) behaves when there is a slave configuration update, so we can design our field workflow correctly.


    We now understand that any PDO/SM related change requires an updated firmware with the updated static array tiesc_eeprom[]. By "slave configuration update" we mean any change to the device descriptor. Our deployment is remote and headless: the master is connected to the slave only over the EtherCAT network, and we want to know what the SDK does end to end and what the master ends up seeing.

    Could you walk us through the SDK's behavior for the following:

    1. According to this thread, 
      e2e.ti.com/.../am6442-ethercat-x…

      The EEPROM is read and the CRC of the first 14 bytes are validated. Then the revision number of the compiled-in array tiesc_eeprom[] is checked against the data in EEPROM at offset 0x0C. If any of the check fails, then the compiled in array is taken as the slave info. So what is the primary source of configuration data, the EEPROM or the static array tiesc_eeprom[]?

     

    1. What the SDK requires for each class of update to take effect on the slave:

    - device descriptors (Device Name, Device HW/SW Version) only

    - identity (Product Code / Revision/Vendor ID/Serial No.) only

    -PDO mapping / SM sizes (process-image change)

                 Specifically, which of these can take effect by updating only the SII in the I2C EEPROM, and which require regenerating tiesc_eeprom.h and/or rebuilding the     firmware because of the identity check and the firmware-side object dictionary?

     

            3. How the master acquires an updated configuration when connected remotely over EtherCAT, with the SDK slave serving the new configuration. Does the SDK expose enough over the wire (SII read via the ESC EEPROM registers, and the OD / PDO mapping via CoE SDO-Information over the mailbox) for a master to pick up the change live, or does the master always need a matching ESI on its own host? Does this differ between an engineering master (TwinCAT) and a scan/online-capable master?

    Essentially, we want a clear picture of the SDK's behavior on a slave configuration update: what the SDK loads and serves, what must be rebuilt vs re-flashed, and what a remotely connected master can and cannot obtain over the EtherCAT link alone.

    Thanks,
    SN

  • 0 in reply to Sapna N
    TI__Genius 14045 points

    Hi Sapna,

    Let me walk through it precisely, with references to the actual SDK source so you can verify against your build.

    1. EEPROM vs. compiled tiesc_eeprom[] — which is primary?

    Neither is "the" primary source uniformly, it depends on what data you're asking about:

    • SII bring-up bytes (identity registers, PDI config, station alias, sync-pulse length): At firmware boot, bsp_eeprom_emulation_init() reads the physical I2C EEPROM into a RAM cache (eeprom_cache, 2048 bytes). It then validates:

      • CRC-8 of the first 14 bytes against the SII checksum byte at offset 14, and
      • the 4 bytes at SII word offset 0x0C (the Revision Number field per ETG.2000) against the same offset in the compiled tiesc_eeprom[] array.

      If either check fails, the entire 2048-byte cache is overwritten from tiesc_eeprom[]. This cache is what the ESC's SII/EEPROM-emulation interface actually serves to the master, and what your ESC identity registers get loaded from (a second pass, bsp_eeprom_load_esc_registers(), re-checks CRC only and loads PDI Control/Alias/Sync-pulse into ESC registers).

      So physical EEPROM content is only honored if its Revision Number already matches the Revision Number baked into the firmware you're running. If you reflash EEPROM with a new Revision Number but don't rebuild/reflash firmware to match, the firmware silently discards your EEPROM write and re-serves the old compiled image.

    • PDO mapping, SM sizes, device descriptor strings, Identity Object 0x1018: These never come from EEPROM/eeprom_cache at all, at any point. They're compiled CoE Object Dictionary content:

      • nPdInputSize/nPdOutputSize are computed by APPL_GenerateMapping() in tiescappl.c by walking objects 0x1C12/0x1C13 and the mapped 0x1600-xx/0x1A00-xx entries; all compiled data.
      • These get checked against the live ESC Sync Manager hardware registers (which the master configures during PREOP→SAFEOP) in ecatslv.c — that's the SMLength != nPdInputSize check highlighted. SMLength comes from the ESC register (set by the master per its ENI), nPdInputSize comes from your compiled Object Dictionary. EEPROM plays no role in either side of that comparison.
      • Identity (0x1018) and descriptor strings (0x1008-0x100A) are #defined constants in ecat_def.h (VENDOR_ID, PRODUCT_CODE, REVISION_NUMBER, SERIAL_NUMBER, DEVICE_NAME, DEVICE_HW_VERSION, DEVICE_SW_VERSION), consumed directly in coeappl.c.

    2. What's required per class of update

    Change SII/I2C EEPROM only? Firmware rebuild required?
    Device descriptors (Name/HW/SW version) No effect: these are compiled CoE constants, never read from EEPROM strings Yes
    Identity (Vendor/Product/Revision/Serial) Technically the SII-level registers (what a plain SII scan sees pre-mailbox) come from eeprom_cache, so a raw EEPROM write would take effect immediately, except the Revision Number field is exactly what's cross-checked against tiesc_eeprom[]. If you don't also rebuild firmware with matching Revision Number, the mismatch trips the fallback and overwrites your EEPROM change back to the compiled identity on the very next boot. So in practice, identity changes need a firmware rebuild too, or they won't survive a power cycle. Effectively yes
    PDO mapping / SM sizes No effect whatsoever, not sourced from EEPROM at runtime Yes — regenerate via tiescappl.xlsx → SSC tool → objdef.c/coeappl.c/ecatappl.c/ecat_def.h + new tiesc_eeprom.h, rebuild, reflash

    3. What a remote master can obtain live over EtherCAT

    Your SDK's SSC-based stack fully implements CoE SDO Information (SDOS_SdoInfoInd() in sdoserv.c, dispatched from the mailbox handler in ecatcoe.c, gated by COE_SUPPORTED=1 in ecat_def.h) — the standard GetODList / GetObjectDescription / GetEntryDescription trio. This means any master capable of live CoE scanning (SDO Information service over the mailbox) can read the true, current PDO mapping (0x1600-0x17FF, 0x1C12/0x1C13) and full OD structure directly from the slave, with no ESI file needed on the host at all. So the SDK does expose everything necessary for a fully live, ESI-less pickup of a configuration change.

    The catch is master policy, not SDK capability, this is the same point from my earlier reply: TwinCAT's default engineering workflow (device scan → box configuration) matches on SII identity (Vendor/Product/Revision) against its local ESI cache first, and if it finds a match it trusts that cached description rather than issuing a live CoE SDO-Info scan. It only falls back to building a config from live CoE/EEPROM data when no cached ESI matches. So with TwinCAT specifically, a remote/headless deployment will keep serving the old PDO layout after a slave update unless either (a) the Revision Number changes, forcing TwinCAT off its stale cache, or (b) you explicitly use "CoE - Online" / trigger a rescan without a matching ESI present.

    Regards,
    Aaron