s32k322 EMAC RMII issue

[YongxiangLi]

Hi,

  We are using the NXP S32K322 MCU and experiencing an Ethernet reception issue: TX (transmission) works normally, but RX (reception) does not function. On the hardware side, the RMII interface is directly connected to an Ethernet switch, and we have verified that the PCB trace length matching and impedance control meet the design requirements. For power sequencing, we currently ensure manually that the switch completes its power-up before the S32K322.

During testing, we have the switch send ARP packets and have measured the RX-related signal waveforms with an oscilloscope, all of which appear correct. However, the S32K322 EMAC does not enter the receive interrupt (the same waveforms are successfully received on another ECU platform). We have also checked the EMAC receive and error counters in the registers, and both read as zero. All clock frequency configurations have been confirmed to be correct. Please help provide additional troubleshooting ideas or suggestions.

Best regards

Yongxiang Li

[PavelL]

Hello @YongxiangLi ,

A few areas look worth checking first. Since TX works but both the RX packet counters and RX error counters remain at 0, I would currently suspect that the EMAC does not recognize valid RMII receive activity at all, rather than receiving frames and dropping them later.

The most important checks would be:

1) RMII reference clock timing during initialization

Please verify that the external 50 MHz RMII reference clock from the switch is already present and stable at the S32K322 pin before the EMAC/pin/clock initialization is executed. Very likely, you will need to add small delay, as it is recommended on S32K3-T-BOX. Please notice also the very first row in code snippet below:

2) RMII clock configuration inside the MCU

For S32K3 RMII, the MAC uses the 50 MHz RMII reference clock on EMAC_MII_RMII_TX_CLK, while the external RX_CLK pin is not used in RMII mode. However, the internal EMAC RX/TX clocks still need to be configured correctly (typically 25 MHz for 100 Mbps, derived from the 50 MHz RMII reference clock). Please double-check the EMAC clock mux/divider settings.

RMII clock for S32K3

3) RMII mode selection

Please confirm that the gmac driver (for EMAC peripheral) is really configured for RMII mode (not MII) and that this selection is done early enough during initialization.

4) Switch-side RMII mode

Because your MAC is connected directly to a switch port rather than to a discrete PHY, please also verify that the switch port is truly configured for RMII/rev-RMII operation and is driving the correct 50 MHz reference clock toward the MCU.

5) Alternatively, you may compare your project with one of my S32K344 EMAC lwIP projects

S32K Examples

To help narrow this down, could you please share:

- What version of S32K3 RTD driver do you use?

- Could you share your project in minimalistic version or mex file at least? 

Best regards,

Pavel

[YongxiangLi]

Hi @PavelL ,

Thanks for your reply. We have check some points provided.

1. The MCU is powered on only after the switch is fully up and running (confirmed to be communicating with other ports). We added the delay shown in the figure, but it didn't help.
2. We checked the clock and reconfigured it, yet the RX counter still shows no new counts.
3. RMII mode is selected in the peripheral config.
4. The switch correctly receives and forwards RMII frames from the TX direction to other ports, so the switch config appears correct. We also scoped the TXCLK provide by switch and MCU RX0/RX1 signals, and the waveforms look fine — no obvious issue with frames from the switch.
5. We are cross-checking against the reference example.

We are on RTD 6.0.0. The test project is attached for verification (apologies in advance for any messy code — this is test firmware).

Best regards

Yongxiang Li

[PavelL]

Hello @YongxiangLi ,

I reviewed your project with big attention to details. I can't see any reason why Rx doesn't work for you. There are small things which can be tuned, but they are so marginal.

What VDD_HV_B do you use?

As a diagnostic step, you may also try enabling promiscuous mode in the GMAC driver.

This will allow the MAC to accept all incoming frames regardless of the destination MAC address filtering, which can help determine whether the issue is related to frame filtering or whether the RX path is not working at a lower level.

If enabling promiscuous mode does not change the behavior and the RX counters still remain at zero, then the issue is more likely below the packet filtering level (for example RMII clocking, RX path initialization, or DMA/descriptor handling).

As another useful debug step, I would recommend stepping back and starting from the standard InternalLoopback example, adapting it to your hardware platform.

First, please verify that the InternalLoopback example works correctly on your board. This helps confirm that the basic GMAC initialization, descriptor handling, buffer configuration, and software flow are working as expected on S32K322.

After that, you can uncheck the internal loopback mode and use the same project as a minimal baseline for communication with the external switch. In other words, keep the example as close as possible to the working reference design and test frame transmission and reception again.

This approach may help isolate whether the issue is related to the hardware interface to the switch (for example RMII timing/clocking) or whether it is caused by some difference in the higher-level software integration of the current project.

Best regards,

Pavel

[YongxiangLi]

Hi @PavelL 

Thank you for your patient support. We will continue the investigation over the weekend as per your suggestions and get back to you by next Monday or Tuesday.

Best regards

Yongxiang Li