AM6421: ECAT: smaller dynamic PDO mappings retain initial padding length

Device: AM64x
TI Industrial Communications SDK: 9.2.0.24
EtherCAT master: TwinCAT Soft PLC 3.1.4024.68

Application and PDO context

Our EtherCAT gateway defines two application-specific PDO mapping objects;

• 0x1A50 — “Fieldbus Flow In”: maps SDO 0x6500:0. This is the device-to-master direction (TxPDO).
• 0x1650 — “Fieldbus Flow Out”: maps SDO 0x7500:0. This is the master-to-device direction (RxPDO).

The gateway defines both 0x6500:0 and 0x7500:0 as variable-length octet strings with a maximum length of 128 bytes. During startup, the application creates and assigns these PDOs with their maximum mappings by registering the PDO and mapped SDO entry, then calls EC_API_SLV_PDO_addPadding() for entries exceeding its 30-byte chunk size, adding padding entries in chunks and a final remainder.

These initial padding entries are part of the maximum-size mapping. They are not intended to remain unchanged when the master selects a smaller process-data size.

The gateway’s CoE/PDO model supports mapping changes during PreOp. Its mapping logic accepts the master’s PDO mapping entries, including continuation/padding entries, applies the resulting mapped length, and updates the gateway’s expected process-data sizes. The TI mapping-change callback also receives the master’s requested entries correctly and forwards them to the application.

Reproduction

TwinCAT writes the PDO mapping during the PreOp→SafeOp transition. The 128-byte mapping works. Reducing the size to 64 or 32 bytes fails for both 0x1A50 and 0x1650.

For a 32-byte 0x1A50 mapping, TwinCAT writes:

1. 0x1A50:0 = 0
2. 0x1A50:1 = 0x650000F0 — SDO 0x6500:0, 240 bits
3. 0x1A50:2 = 0x00000010 — 16 bits of padding
4. 0x1A50:0 = 2

The entries reported by the TI mapping-change callback match the values written by the master. However, after the transition fails, reading 0x1A50:2 from the master returns 0x000000F0—the initial padding value—instead of 0x00000010. The same stale-padding behavior occurs for 0x1650.

The slave reports AL status 0x0012, with AL status code 0x001E (“Invalid SM IN cfg”).

Expected and observed behavior

The gateway can apply the requested shorter mapping and update its expected process-data size. The fieldbus stack should use that same new mapping when serving subsequent mapping-object reads and validating the SyncManager configuration.

Instead, the callback reports the new entry, but the stack’s readback/validation path appears to retain the startup padding value. This is consistent with the SafeOp rejection.

Request to TI

Please investigate how the EtherCAT stack commits a dynamic PDO mapping after the mapping-change callback, specifically whether the mapping used for:

• CoE reads of 0x1A50 / 0x1650, and
• SyncManager/process-data-length validation during PreOp→SafeOp

is updated from the master’s new mapping, including shortened continuation/padding entries.

Please confirm whether these application-defined PDOs and smaller mappings are supported in SDK 9.2.0.24, and provide a fix or required workaround/sequence. The callback-versus-readback discrepancy and the resulting AL error are the key evidence; the exact internal cause remains for TI to confirm.