• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 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.

AM2432: EtherCAT. PHY Polling Based Link Detection (LINKSEL=0) Fails at INIT→PREOP in SDK 2025 — Works in SDK 11

Seungho Yu
Prodigy 155 points

Part Number: AM2432
Other Parts Discussed in Thread: SYSCONFIG

  1. Background

    We are migrating an EtherCAT CiA402 subdevice from SDK 11 (ind_comms_sdk_am243x_11_00_00_13) to SDK 2025 (ind_comms_sdk_am243x_2025_00_00_08) on a custom PCB with DP83822 PHY on AM243x (ICSSG1).

    In SDK 11, we successfully resolved an RXLINK pin glitch issue on our custom PCB by switching from MLINK Based to PHY Polling Based link detection (ECAT_PHYUSERXLINK_IN = false, LINKSEL=0). This configuration reaches OP stably.

    We attempted to apply the same approach in SDK 2025 but it fails consistently.

    please refer: testResult01.zip 

    Original SDK Example Comparison

    SDK 11 original (ind_comms_sdk_am243x_11_00_00_13/.../ESL_BOARD_config.h):

    // No ti_drivers_config.h include, no ENHANCED_LINK_ENABLED
#define ECAT_PHYUSERXLINK_IN    (true)   // MLINK Based (hardware MDIO normal mode)
#define ECAT_PHYPOLINVERT_IN    (true)   // ACTIVE_HIGH

    SDK 2025 original (ind_comms_sdk_am243x_2025_00_00_08/.../ESL_BOARD_config.h):

    #include "ti_drivers_config.h"   // Contains ENHANCED_LINK_ENABLED
#ifdef ENHANCED_LINK_ENABLED
    #define ECAT_PHYUSERXLINK_IN    (true)   // MLINK Based (MDIO manual mode, errata i2329)
    // Polarity from SysConfig (PHY0_LINK_POLARITY_ACTIVE_HIGH)

    Key difference: SDK 11 does not use MDIO manual mode (ENHANCED_LINK_ENABLED absent). SDK 2025 always uses MDIO manual mode.

    Working Reference: SDK 11 Custom Project

    Our working SDK 11 custom project (ethercat_subdevice_cia402_clang_IND11_shyu3test) uses LINKSEL=0 as a workaround for RXLINK pin glitch sensitivity:

    #define ECAT_PHYUSERXLINK_IN    (false)   // LINKSEL=0, PHY Polling Based
#define ECAT_PHYPOLINVERT_IN    (true)    // ACTIVE_HIGH

    UART boot output (stable, OP reached):

    Configure Phy bits: PhyAddr:3, LinPol:HIGH, PhyAddr:1, LinPol:HIGH, (0x0)
...
PDO size In:0x27/0xd
PDO size Out:0x27/0xd, In:0x27/0xd   ← OP reached, stable

    MDIO_LINK (0x300B240C) = 0x00000800 — stable, no oscillation.

    SDK 2025 Test Results — LINKSEL=0 Always Fails

    Test A: Manual ESL_BOARD_config.h edit (LINKSEL=0 + ACTIVE_HIGH)

    #define ECAT_PHYUSERXLINK_IN    (false)
#define ECAT_PHYPOLINVERT_IN    PHY_LINK_POL_ACTIVE_HIGH

    Result: TwinCAT SCAN fails completely — slave device not detected.

    Test B: SysConfig — "Enable Enhanced Link" unchecked → PHY Polling Based

    ti_drivers_config.h after SysConfig change: ENHANCED_LINK_ENABLED removed.

    UART boot output:

    Configure Phy bits: PhyAddr:3, LinPol:LOW, PhyAddr:1, LinPol:LOW, (0xa)
...
SSC_checkTimer:MaxET:25
← No PDO size output, OP never reached

    TwinCAT result:

    • SCAN: device detected (Box 1 visible) OK
    • INIT → PREOP: failed — Communication Error 0x71f (1823) not OK

    Note: FW config still shows (0xa) even with PHY Polling Based, unlike SDK 11 which shows (0x0).

    Summary Table

    Configuration SCAN PREOP OP Notes
    SDK 2025, LINKSEL=1, ACTIVE_HIGH (original) Fail — — Device not detected
    SDK 2025, LINKSEL=1, ACTIVE_LOW Pass Pass Pass ~1 sec Port A oscillation
    SDK 2025, LINKSEL=0, ACTIVE_HIGH (manual) Fail — — Device not detected
    SDK 2025, LINKSEL=0, PHY Polling Based (SysConfig) Pass Fail 0x71f — Consistent failure
    SDK 11, LINKSEL=0, PHY Polling Based Pass Pass Pass Stable reference

    Questions

    1. Why does PHY Polling Based link detection (ECAT_PHYUSERXLINK = false, Enhanced Link disabled) fail at INIT→PREOP with error 0x71f in SDK 2025, while the identical LINKSEL=0 configuration works correctly in SDK 11?

    2. In SDK 2025 with PHY Polling Based selected via SysConfig, the UART still prints FW config (0xa) — the same value as MLINK Based mode. In SDK 11, PHY Polling Based produces (0x0). Does SDK 2025's PHY Polling Based mode use a different internal implementation than SDK 11? Is there an additional configuration step required?

    3. Is PHY Polling Based link detection (ECAT_PHYUSERXLINK = false) officially supported in SDK 2025 with MDIO manual mode (errata i2329)? If not, what is the recommended approach for customers whose custom PCB has RXLINK pin glitch sensitivity?

if you need more informaion, please request it to me.

  • 0
    Prodigy 155 points

    more info, let you know. 

    i got strap register data from my custom PCB of strap states below.


    This result was identical in both the "ind_comms_sdk_am243x_11_00_00_13" and "ind_comms_sdk_am243x_2025_00_00_08" examples.

  • 0 in reply to Seungho Yu
    TI__Expert 4340 points

    Hello Seungho Yu,

    I was able to reproduce the issue in PHY polling mode at my end on AM243x target, and the fix will be included in upcoming release.

    As a work around, you could add the below code in the function EC_SLV_APP_SS_registerStacklessBoardFunctions() in ecSubDeviceSimple.c file.

    /* Write 0x01 to MDIO Mode Selection Register 0x0E35 to select firmware workaround mode for MDIO before running the PRU core */

/* Method 1 */
uint32_t regData = 0;
regData = CSL_REG32_RD_RAW((uint32_t*)(0x30090E34));
regData |= (0x00000100);
CSL_REG32_WR_RAW((uint32_t*)(0x30090E34),regData);

/* Method 2 */
uint8_t regVal = 0;
/* Note: This API is designed to be used after the initialization of SubDevice handler.
In this case, it is called before the SubDevice init with a handler to EC_API_SLV_SHandle_t, which is not NULL */  
EC_API_SLV_writeByteEscRegister((EC_API_SLV_SHandle_t*)pAppInstance_p,0xE35,0x01);
EC_API_SLV_readByteEscRegister((EC_API_SLV_SHandle_t*)pAppInstance_p,0xE35,&regVal);
OSAL_printf("Register 0xE35 value = %d\n\r",regVal);

    Also, kindly configure the PHY link polarity correctly in ESL_BOARD_config.h file. To configure the link polarity, refer EtherCAT Debug Guide. 

    Please refer Controller Register List and MDIO Manual Mode for more details.

    Kind Regards,

  • 0 in reply to Harsha Begihally Shanmukhaswamy
    Prodigy 155 points

    Hello Harsha,

    Thank you very much for the workaround and the prompt response. I'm happy to report that the migration is now fully working. Here is a summary of what I applied and the result, for the record.

    Applied Changes

    1) 0xE35 workaround (your suggested code, Method 2)

    Since our project is based on the CiA402 example (ecSubDeviceCiA402.c), I added the workaround at the entry of EC_SLV_APP_CIA_registerStacklessBoardFunctions() — the CiA402 counterpart of the ecSubDeviceSimple.c function you referenced:

    void EC_SLV_APP_CIA_registerStacklessBoardFunctions(EC_SLV_APP_CIA_Application_t *pAppInstance_p)
{
    /* TI_ADVICE: SDK 2025 PHY Polling Based bug workaround.
     * Apply only when MDIO Manual Mode FW is configured for PHY Polling Based
     * link detection (LINK_POLLING_ENABLE bit set). */
#if defined(MDIO_MANUAL_MODE_FW_CONFIG_VALUE) && \
    ((MDIO_MANUAL_MODE_FW_CONFIG_VALUE) & MDIO_MANUAL_MODE_LINK_POLLING_ENABLE)
    {
        uint8_t regVal = 0;
        EC_API_SLV_writeByteEscRegister((EC_API_SLV_SHandle_t*)pAppInstance_p, 0xE35, 0x01);
        EC_API_SLV_readByteEscRegister((EC_API_SLV_SHandle_t*)pAppInstance_p, 0xE35, &regVal);
        OSAL_printf("Register 0xE35 value = %d\n\r", regVal);
    }
#endif
    /* ... rest of original function ... */
}

    I wrapped it in a preprocessor guard tied to the SysConfig-generated MDIO_MANUAL_MODE_FW_CONFIG_VALUE, so the workaround is only compiled in when the project is configured for PHY Polling Based mode. That way the same source can be toggled cleanly via SysConfig later (e.g., to verify the official fix once it ships).

    2) SysConfig — Enable Enhanced Link unchecked

    This switched "MDIO Manual Mode Link Status Update" automatically to PHY Polling Based, dropped ENHANCED_LINK_ENABLED, and set:

    #define MDIO_MANUAL_MODE_FW_CONFIG_VALUE \
    (MDIO_MANUAL_MODE_LINK_POLLING_ENABLE | MDIO_MANUAL_MODE_LINK_POLLING_INTR_ENABLE | MDIO_MANUAL_MODE_PRU_CLK_FREQ_200)

    3) ESL_BOARD_config.h — PHY link polarity per your guidance

    In the #else branch (active when ENHANCED_LINK_ENABLED is undefined):

    #define ECAT_PHYUSERXLINK_IN     (false)
#define ECAT_PHYUSERXLINK_OUT    (false)
#define ECAT_PHYPOLINVERT_IN     PHY_LINK_POL_ACTIVE_HIGH
#define ECAT_PHYPOLINVERT_OUT    PHY_LINK_POL_ACTIVE_HIGH

    ACTIVE_HIGH was chosen because in PHY Polling Based mode the link status is derived from BMSR.LINK_STS, which is active-high per IEEE 802.3. The raw MLINK pin polarity (measured as active-low on our custom PCB via MDIO_LINK_REG toggling at 0x300B240C) is not relevant in this mode.

    Results

    Item Result
    UART Register 0xE35 value = 1 printed ✓
    Configure Phy bits print PhyAddr:3, LinPol:HIGH, PhyAddr:1, LinPol:HIGH, (0x0)
    TwinCAT SCAN Box detected with full ESI name "TI EtherCAT Toolkit CiA402 for AM243X..." ✓
    INIT → PREOP → SAFEOP → OP All transitions successful ✓
    Port A Carrier / Open, stable (no oscillation) ✓
    CiA402 PDOs Statusword, Modes of operation, Position/Velocity/Torque actual — all mapped and updating ✓

    Thank you for your help. I have correctly completed the custom_phy settings, and the "Enhanced Link" and "MLINK-based" features have been successfully implemented.
    This attached file is a custom_phy file I created. Please give me some advise if there are any errors.
    Click to the download page link.


    May I ask something else?
    1. Should I apply the /* Method 2 */ patch to the EC_SLV_APP_SS_registerStacklessBoardFunctions() function (MLINK-based)? Or should I leave the code as is to use only the polling-based method?

    2. You distributed IND_SDK2026 in two versions: ind_comms_sdk_am243x_2026_00_00_06 and ind_comms_sdk_am243x_2026_00_00_06_eval. It appears there are differences in the .lib files between the two versions.
    Which version is suitable for an actual production environment?
    Do they perform different functions?

    3. Can we assume that the IND_SDK2026 example is identical to the IND_SDK2025 example? Are there any other settings or changes?

     -aspect of blackbox  EC SubDevice, HWAL firmware bin

  • +1 in reply to Seungho Yu
    TI__Expert 4340 points

    Hello Seungho Yu,

    Thanks for the confirmation.

    Seungho Yu said:
    1. Should I apply the /* Method 2 */ patch to the EC_SLV_APP_SS_registerStacklessBoardFunctions() function (MLINK-based)? Or should I leave the code as is to use only the polling-based method?

    Writing 0x01 to MDIO Mode Selection Register (0xE35) selects the Firmware workaround for MDIO communication and should be applicable for both MLINK-based and polling-based link status update.

    Seungho Yu said:
    2. You distributed IND_SDK2026 in two versions: ind_comms_sdk_am243x_2026_00_00_06 and ind_comms_sdk_am243x_2026_00_00_06_eval. It appears there are differences in the .lib files between the two versions.
    Which version is suitable for an actual production environment?
    Do they perform different functions?

    Kindly specify the sources of ind_comms_sdk_am243x_2026_00_00_06 and ind_comms_sdk_am243x_2026_00_00_06_eval. 

    Please refer to License Types.

    Seungho Yu said:

    3. Can we assume that the IND_SDK2026 example is identical to the IND_SDK2025 example? Are there any other settings or changes?

     -aspect of blackbox  EC SubDevice, HWAL firmware bin

    Please refer to the Release Notes 2026.00.00 page.

    Kind Regards,