• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 166 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.

AM6442: Ethercat xml, EEPROM FLASH

ganesh d
Prodigy 130 points

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Hi TI Team,

I am using the AM6442 EtherCAT Slave example on R5FSS1_1 (ICSSG1) with Industrial Communications SDK 11.00.

Could you please clarify how the EtherCAT EEPROM (ESI/SII) data is loaded by default during startup?

  • Is the default SDK having the feature of EEPROM data read from an external I2C EEPROM?
  • Or does the stack use EEPROM emulation (for example, default_tiesc_eeprom)?
  • Which source file/function is responsible for loading the EEPROM contents?
  • How can I verify whether my application is using external EEPROM or EEPROM emulation?
  • what is the recommended procedure to program/update the EtherCAT EEPROM (SII) image? Is there a TI utility available, or should the EEPROM binary be programmed using an external EEPROM programmer or custom I2C application?
  • Also Please note I could be able to detect my slave device from twincat, but when I am trying to load new ESI file using SSC EEPROM tool that information is not reflected in Twincat while scanning the slave device....

    Our primary goal is to flash EEPROM and confirm it from Twincat, we need dynamic way of flashing the I2C EEPROM not through FOE method, Kindly suggest

Thanks, Ganesh D

  • 0
    TI__Genius 15175 points

    Hi Ganesh,

    Which EtherCAT SubDevice demo are you using here for validation?

    Regards,
    Aaron

  • 0 in reply to Aaron Thomas
    Prodigy 130 points

    Hi Aaron,

    I am using ethercat_slave_beckhoff_ssc_demo EtherCAT stack.Kindly let us know how to flash I2C physical eeprom and how to acquire the SII info with updated firmware for slave device. Where does the code change is required 

    Thanks,

    Ganesh D

  • 0 in reply to ganesh d
    TI__Genius 15175 points

    Hi Ganesh,

    Thanks for the details. Let me answer each question for the ethercat_slave_beckhoff_ssc_demo:

    EEPROM loading at startup

    The demo uses EEPROM emulation: a 2048-byte RAM cache (eeprom_cache[]) backed by physical storage. The loading flow in bsp_eeprom_emulation_init() is:

    1. Read 2048 bytes from the I2C EEPROM into the RAM cache
    2. Validate the CRC of the first 14 bytes (EtherCAT EEPROM header CRC per ETG.2000)
    3. Check 4 bytes at SII offset 0x0C (Revision Number) against the compiled-in tiesc_eeprom[]
    4. If any check fails → load from the compiled-in default array tiesc_eeprom[] in tiesc_eeprom.h
    5. Point the EtherCAT stack's pEEPROM pointer at the RAM cache

    The responsible file/function is bsp_eeprom_emulation_init() in source/industrial_comms/ethercat_subdevice/icss_fwhal/tiescbsp.c.

    ganesh d said:
    Is the default SDK having the feature of EEPROM data read from an external I2C EEPROM?

    Both, that is, the I2C EEPROM provides persistent storage, but all live accesses by the EtherCAT stack go through the RAM cache. At startup you will see one of these log lines (SDK 2026.00 only, SysConfig-selectable):

    Application using ESI EEPROM over I2C EEPROM
    Application using ESI EEPROM over SPI Flash

    The I2C EEPROM handle is gEepromHandle[CONFIG_EEPROM0] opened by Board_init(). The offset within the I2C EEPROM is 0x8000 (32 KB in).

    Why your SSC EEPROM write is not reflected after a power cycle

    The SSC EEPROM tool write is the correct mechanism — it writes via ESC register 0x502, the FWHAL detects it, updates the RAM cache, and after ~100ms flushes to the I2C EEPROM. The write itself is working.

    The problem may be on the next boot: the identity check at byte offset 24 (SII Revision Number field) compares the stored ESI against the compiled-in default. If your new ESI has a different Revision Number, the firmware rejects the stored data and falls back to the compiled-in default. This is why TwinCAT still sees the original device.

    To persist a custom SII:

    1. Generate your custom SII binary (e.g. from ETG SSC Tool or ESI Workbench)
    2. Update tiesc_eeprom.h in your board folder (e.g. examples/…/am64x-evm/tiesc_eeprom.h) with the new byte array
    3. Rebuild the firmware which is now the compiled-in default and the stored SII agree, so the identity check passes

    TwinCAT not showing the updated device description

    TwinCAT reads Vendor ID + Product Code from the SII to look up a matching ESI XML file in its local library (C:\TwinCAT\3.1\Config\Io\EtherCAT\). It does not display device description strings from the EEPROM directly. To see the new description in TwinCAT:

    1. Install the updated ESI XML file in TwinCAT's ESI folder
    2. Reload the device library in TwinCAT by restarting TwinCAT application.
    3. Rescan the Box.

    Recommendation: migrate to SDK 2026.00

    SDK 2026.00 adds:

    • SPI Flash as an alternative ESI storage backend — selectable in SysConfig, customer can use ESI over I2C EEPROM (default) or SPO Flash.
    • First-boot auto-programming: if the storage is blank or the identity check fails, the firmware now automatically writes the compiled-in default back to storage, so the next boot always loads from storage cleanly
    • This means in SDK 2026, once you update tiesc_eeprom.h and flash the firmware once, the I2C EEPROM (or SPI Flash) is self-initialized on first boot without any separate programming step

    Please migrate to SDK 2026.00 and let us know if the issue persists.

    Regards,
    Aaron