Troubleshooting RT1064 ENET2 RMII Clock and RX Guide

An RT1064 ENET2 interface can show a valid 50 MHz RMII reference clock and visible receive activity while remaining unable to transmit or generate interrupts. In the documented configuration, operation required four coordinated corrections: use the ENET2 RX_EN input instead of CRS, accept the reference clock from the external switch, force the reference-clock pad input path on, and place the non-cacheable Ethernet data section in DTC RAM.

Recognize the ENET2 Failure Pattern

The affected custom board connected an RT1064 to an Ethernet switch through RMII and used MCUXpresso IDE v11.02 with MCU SDK v2.62. Initial measurements showed a 50 MHz clock and activity on the receive-data lines, but no transitions on TX_EN or TX_Dx. Calls reached ENET_ActiveSend(), while ENET_TransmitIRQHandler() was not entered.

Later configurations produced limited traffic—one UDP datagram or a small number of interrupts—before communication stopped. That progression separates a complete clock or mux failure from a descriptor-memory coherency problem.

Separate the Four Required Conditions

Configure the External RMII Reference Clock

For the verified external-switch clock arrangement, enable ENET2 reference-clock input mode and disable the ENET2 transmit-clock output direction:

IOMUXC_EnableMode(IOMUXC_GPR,
                   kIOMUXC_GPR_ENET2RefClkMode,
                   true);
IOMUXC_EnableMode(IOMUXC_GPR,
                   kIOMUXC_GPR_ENET2TxClkOutputDir,
                   false);

Configure GPIO_B0_15 as ENET2_REF_CLK2 and force its input path:

IOMUXC_SetPinMux(
    IOMUXC_GPIO_B0_15_ENET2_REF_CLK2,
    1U); /* Software Input On: force input path */

The pin-level presence of 50 MHz alone does not verify that ENET2 receives the clock internally. Confirm both the GPR clock mode and the pad input setting.

Apply the Corrections in a Controlled Sequence

1. Wire and mux the switch receive-enable output to the ENET2 RX_EN input. Do not use ENET2_CRS on GPIO_B0_10 for this resolved RMII configuration.
2. Configure the switch to supply the 50 MHz reference clock and apply the two IOMUXC_EnableMode() calls shown above.
3. Configure GPIO_B0_15 as IOMUXC_GPIO_B0_15_ENET2_REF_CLK2 with Software Input On set to 1U.
4. Map *(NonCacheable.init) into DTC RAM. Disabling SCB_EnableDCache() restored operation during diagnosis, but the final correction was proper non-cacheable section placement.
5. Rebuild, transmit a packet, and then test traffic in the reverse direction. Treat TX and RX as separate verification paths.

LWIP_MPU_COMPATIBLE set to 1 did not correct the observed cache-related failure. The failure also occurred with the MPU enabled or disabled after global data and the FreeRTOS heap_4 were moved to SRAM_OC.

Verify Operation and Isolate Remaining Faults

For transmit verification, confirm transitions on TX_EN and TX_Dx, entry into the transmit interrupt path, and packet arrival beyond the switch. For receive verification, confirm that RX data and RX_EN are synchronized to the 50 MHz reference clock, that receive interrupts continue rather than stopping after a few events, and that the packet reaches the lwIP UDP layer.

If the MCU-side configuration passes those checks but no traffic returns from the switch, verify that the switch is actually enabled after bootstrap. A separate RT1062 implementation using a KSZ8895 produced no return traffic because the switch started in a mode where switching was disabled; correcting the switch configuration restored Ethernet operation.

The tested driver also reached an error-interrupt path where s_enetErrIsr was NULL. Commenting out the callback avoided the immediate hard fault during diagnosis, but this does not establish a general driver repair. Inspect callback initialization and ENET2 instance-handle setup before suppressing error handling. One project expanded the handle table to {NULL,NULL,NULL} after observing an ENET2 out-of-bounds access; verify the required instance count against the exact driver source in use.

FAQ