AM2432: PRU Firmware loading will clear the register of TXCFG0_TX_CLK_DELAY

Hi Zekun,

The EtherCAT PRU firmware rewrites the full MII_RT_TXCFG0/1 registers — including bits 30:28 (TX_CLK_DELAY) — every time a port state change is detected. This happens repeatedly during firmware initialization as the port scanning loop runs, which is why any pre-load write gets overwritten and a post-load write only "sticks" once the firmware has settled.

Recommended Solution (no firmware change):

Set the TX_CLK_DELAY bits inside the TI_VS_PORT0_TX_START_DELAY shared RAM parameter before enabling the PRU cores. The SDK populates this parameter during EtherCAT stack initialization. Include the desired TX_CLK_DELAY value in bits 14:12 of both the FWD and REV TX_START_DELAY 16-bit words:

bsp_init() writes the TX start delay to PRUSS Data RAM at ESC_ADDR_TI_PROCESS_PATH_TX_START_DELAY (offset 0xE10) before the PRU firmware is loaded. When the PRU firmware starts, it reads this word from DRAM and writes it to the MII_RT_TXCFG hardware register.

Because the stored word only encoded TX_START_DELAY (bits 9–0) and left bits 14–12 as zero, the PRU firmware always write TX_CLK_DELAY=0, overwriting any value written directly to the hardware register before the PRU started.

By encoding TX_CLK_DELAY in bits [14:12] of the value written to DRAM[0xE10-0xE11], the PRU firmware will automatically preserve the correct TX_CLK_DELAY setting every time it initializes the MII_RT_TXCFG register. No post-load write and no 2-second delay are needed.

Background

The 16-bit word written to ESC_ADDR_TI_PROCESS_PATH_TX_START_DELAY (PRUSS DRAM offset 0xE10) maps directly to bits [31:16] of the MII_RT_TXCFG hardware register. Two independently configurable fields are packed into this word:

  Address   Byte     Bits      MII_RT_TXCFG field
  --------  -------  --------  ---------------------------
  0xE10     low      [7:0]     TX_START_DELAY[7:0]
  0xE11     high     [6:4]     TX_CLK_DELAY   (3-bit, 0–7)
                     [1:0]     TX_START_DELAY[9:8]  (always 0 for current values)

Previously these were written together as a single bsp_write_word. The change splits them into two bsp_write_byte calls so each field is configured and understood independently.

Changes to tiescbsp.h

Added — new TIESC_TX_CLK_DELAY_BYTE helper and user knob:

/*
 * TX_CLK_DELAY high-byte value for ESC_ADDR_TI_*_TX_START_DELAY + 1.
 * Bits [6:4] of the high byte map to TX_CLK_DELAY bits [30:28] in MII_RT_TXCFG.
 * Adds (n*5 + 10) ns + SOC delay per step (n = 0..7).
 * NOTE: Per TRM, keep at 0h (default) for guaranteed MII_G_RT I/O timing
 * at 200/225/250 MHz core clock.
 */
#define TIESC_TX_CLK_DELAY_BYTE(n)    ((uint8_t)((n) << 4U))

/* TX_CLK_DELAY for process (forward) path: 0 = default; set to 1-7 to add MII launch delay */
#define TIESC_PROCESS_PATH_TX_CLK_DELAY    3U
Unchanged — existing TX_START_DELAY macros (now used as the low byte):

#if ENABLE_MULTIPLE_SM_ACCESS_IN_SINGLE_DATAGRAM
#define TIESC_PROCESS_PATH_TX_DELAY_200_MHZ_CLOCK    0x98
#else
#define TIESC_PROCESS_PATH_TX_DELAY_200_MHZ_CLOCK    0x48
#endif
#define TIESC_AUTOFORWARD_PATH_TX_DELAY_200_MHZ_CLOCK    0x38

#if ENABLE_MULTIPLE_SM_ACCESS_IN_SINGLE_DATAGRAM
#define TIESC_PROCESS_PATH_TX_DELAY_333_MHZ_CLOCK    0xA0
#else
#define TIESC_PROCESS_PATH_TX_DELAY_333_MHZ_CLOCK    0x50
#endif
#define TIESC_AUTOFORWARD_PATH_TX_DELAY_333_MHZ_CLOCK    0x30

Changes to tiescbsp.c

Before (single 16-bit write, TX_CLK_DELAY was always 0):

bsp_write_word(pruIcssHandle, TIESC_PROCESS_PATH_TX_DELAY_200_MHZ_CLOCK,
            ESC_ADDR_TI_PROCESS_PATH_TX_START_DELAY);
bsp_write_word(pruIcssHandle, TIESC_AUTOFORWARD_PATH_TX_DELAY_200_MHZ_CLOCK,
            ESC_ADDR_TI_AUTOFORWARD_PATH_TX_START_DELAY);
After (two separate byte writes for process path):

/* Process (forward) path TX_START_DELAY: low byte of the 16-bit word at
 * ESC_ADDR_TI_PROCESS_PATH_TX_START_DELAY. Maps to MII_RT_TXCFG bits[23:16].
 * Controls the number of MII_RT clock cycles after RXDV before TX starts. */
bsp_write_byte(pruIcssHandle, TIESC_PROCESS_PATH_TX_DELAY_200_MHZ_CLOCK,
            ESC_ADDR_TI_PROCESS_PATH_TX_START_DELAY);

/* Process (forward) path TX_CLK_DELAY: high byte of the same 16-bit word.
 * Bits[6:4] map to MII_RT_TXCFG bits[30:28]. Controls the number of
 * MII_RT clock cycles to wait before launching TX data on the MII interface.
 * Configured separately so TX_START_DELAY and TX_CLK_DELAY can be tuned
 * independently. Set TIESC_PROCESS_PATH_TX_CLK_DELAY (0-7) in tiescbsp.h. */
bsp_write_byte(pruIcssHandle, TIESC_TX_CLK_DELAY_BYTE(TIESC_PROCESS_PATH_TX_CLK_DELAY),
            ESC_ADDR_TI_PROCESS_PATH_TX_START_DELAY + 1U);

/* Autoforward path TX_START_DELAY: written as a single 16-bit word.
 * TX_CLK_DELAY is not configured for the autoforward path (kept at 0). */
bsp_write_word(pruIcssHandle, TIESC_AUTOFORWARD_PATH_TX_DELAY_200_MHZ_CLOCK,
            ESC_ADDR_TI_AUTOFORWARD_PATH_TX_START_DELAY);
The same pattern applies for the 333 MHz branch.

How to Configure TX_CLK_DELAY

Change only this one line in tiescbsp.h:

#define TIESC_PROCESS_PATH_TX_CLK_DELAY    3U   /* 0 = default; 1–7 = additional delay */

The auto-forward path is intentionally kept as bsp_write_word with no TX_CLK_DELAY component (the auto-forward path has tighter latency requirements).

Files Changed Summary

Attaching the updated files for reference. Make sure to rebuild the FWHAL: 0143.tiescbsp.c tiescbsp.h

Do note that these changes are made with respect to Industrial Communications SDK 2025.00.00.08.

Regards,
Aaron