S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

[brunoGT88]

Hello,

I am working with Ethernet on an S32K344, using the S32K344 Mini EVB as the base board. The project uses the RTD Eth_43_GMAC driver, without lwIP. The application is based on the NXP ethernet_no_lwip example, but adapted to our board

The hardware uses a Microchip/Micrel KSZ8091RND PHY in RMII mode. The PHY receives a 50 MHz clock on the XI pin, according to our schematic. In the KSZ8091RND PHY Control 2 register, bit 7, RMII Reference Clock Select, is 0. We understand this to be consistent with the RND mode using a 50 MHz clock on XI.

The interface between the MCU and the PHY is configured as RMII, 100 Mbps, full-duplex.

In the .mex file, the GMAC/EMAC pins are configured as follows:

PTD16, pin 34: RMII_MDIO, emac_mii_rmii_mdio
PTD17, pin 31: RMII_MDC, emac_mii_rmii_mdc
PTB5, pin 47: RMII_TX0, emac_mii_rmii_txd0
PTB4, pin 48: RMII_TX1, emac_mii_rmii_txd1
PTE9, pin 36: RMII_TX_EN, emac_mii_rmii_tx_en
PTC0, pin 62: RMII_TX_CLK, emac_mii_rmii_tx_clk
PTD9, pin 63: RMII_RX0, emac_mii_rmii_rxd0
PTD8, pin 64: RMII_RX1, emac_mii_rmii_rxd1
PTC15, pin 68: RMII_RX_DV, emac_mii_rmii_rx_dv
PTC16, pin 66: RMII_RX_ER, emac_mii_rmii_rx_er
PTC1, pin 61: RMII_RX_CLK, emac_mii_rx_clk
PTE21, pin 153: ENET_RESET

Relevant Ethernet configuration in the .mex file:

EthCtrlMacLayerType = ETH_MAC_LAYER_TYPE_XMII
EthCtrlMacLayerSubType = REDUCED
EthCtrlMacLayerSpeed = ETH_MAC_LAYER_SPEED_100M
EthDuplexMode = ETH_FULL_DUPLEX
EthCtrlEnableRxInterrupt = false
EthCtrlEnableTxInterrupt = false

Relevant GMAC configuration generated by RTD:

miiMode = GMAC_RMII_MODE
speed = GMAC_SPEED_100M
duplex = GMAC_FULL_DUPLEX

We also checked that the driver selects the RMII interface before resetting the controller. In Eth_43_GMAC_Ipw.c, when the mode is GMAC_RMII_MODE, it writes DCMRWF1 MAC_CONF_SEL with value 2U.

So, based on the generated code, MAC_CONF_SEL appears to be configured for RMII.

Regarding clocks, the .mex file shows:

external_clocks.emac_mii_rmii_tx.outFreq = 50 MHz
EMAC_MII_RMII_TX.outFreq = 50 MHz
EMAC0_RX_CLK.outFreq = 25 MHz
EMAC0_TX_CLK.outFreq = 25 MHz
EMAC0_TS_CLK.outFreq = 50 MHz

The EMAC clock muxes use EMAC_MII_RMII_TX_CLK as their source:

McuCgm0ClockMux7_Source = EMAC_MII_RMII_TX_CLK
McuCgm0ClockMux8_Source = EMAC_MII_RMII_TX_CLK
McuCgm0ClockMux9_Source = EMAC_MII_RMII_TX_CLK

When comparing this with NXP example .mex files, we saw that they also show EMAC_MII_RMII_TX at 50 MHz and EMAC0_RX_CLK / EMAC0_TX_CLK at 25 MHz, so we assume this may be normal in the tool, but we would like to confirm.

The application transmits and receives Ethernet frames directly through Eth_43_GMAC, without lwIP.

For TX, we use this sequence:

Eth_43_GMAC_ProvideTxBuffer
Eth_43_GMAC_Transmit
Eth_43_GMAC_TxConfirmation

For RX, we use polling, since RX/TX interrupts are disabled:

ETH_43_GMAC_RX_IRQ_ENABLED = STD_OFF
ETH_43_GMAC_TX_IRQ_ENABLED = STD_OFF

The RX code repeatedly calls Eth_43_GMAC_Receive with CtrlIdx, FifoIdx, and receiveStatus.

We also monitor EthIf_RxIndications[0], because the driver only calls EthIf_RxIndication when the received frame has no error.

The observed behavior is:

TX is confirmed successfully several times.

On the other side, some frames appear to be received.

RX on the S32K344 receives something, but then all frames are discarded by the driver.

receiveStatus may indicate that a frame was received.

However, EthIf_RxIndication is not called because the driver detects an error in the frame.

When inspecting Eth_43_GMAC_Ipw_axRxFrameInfo[0][0].ErrMask, the observed value is:

ErrMask = 0x01080000

According to the driver header, this corresponds to:

GMAC_RX_ERR_CRC_ERROR = 0x01000000
GMAC_RX_ERR_DRIBBLE_ERROR = 0x00080000

So the frame reaches the GMAC, but it is marked with CRC and dribble errors.

The main question is: considering that the GMAC is configured as RMII 100M full-duplex, the KSZ8091RND PHY receives a 50 MHz clock on XI, and the driver selects MAC_CONF_SEL value 2U, what could cause simultaneous CRC and dribble errors on RX?

We would especially like to confirm:

1. For S32K344 plus GMAC plus RMII, is it expected that the .mex file shows EMAC_MII_RMII_TX = 50 MHz, but EMAC0_RX_CLK and EMAC0_TX_CLK as 25 MHz?

2. In RMII mode on S32K344, is it expected to configure both emac_mii_rmii_tx_clk on PTC0 and emac_mii_rx_clk on PTC1, or should one of these signals not be used or routed in this mode?

3. Is any additional configuration required in DCM_GPR, the clock tree, or pin mux for RMII besides MAC_CONF_SEL value 2U?

4. Is the KSZ8091RND with bit 7 of PHY Control 2 set to 0 and an external 50 MHz clock on XI compatible with this GMAC configuration?

5. In cases of CRC_ERROR plus DRIBBLE_ERROR on RX, which RMII signals would you recommend checking first with an oscilloscope or logic analyzer? REF_CLK, CRS_DV, RXD0, RXD1, RX_ER?

6. Is there any official NXP example for S32K344 using a KSZ8091RND PHY in RMII mode without lwIP?

Summary: the link comes up, TX is confirmed, and RX detects frames, but the frames are discarded due to CRC_ERROR plus DRIBBLE_ERROR. We are trying to determine whether this points to an RMII clock issue, pin mux/physical signal issue, or some additional GMAC/RTD configuration requirement.

Thank you in advance for your support and guidance.

[brunoGT88 · Accepted solution]

Hi @PavelL ,

I found the root cause.

The issue was related to the initialization order. In my project, the MCU-clock initialization was being executed before the SIUL2 pin mux initialization. After changing the startup flow so that the pin mux configuration is done first, before MCU clock initialization, the Ethernet frames are now transmitted correctly.

This also matches the initialization order used in the clean NXP example I compared against.

Thank you for the support.

[PavelL]

Hello @brunoGT88 ,

Thank you for the very detailed description. I reviewed your setup carefully.

Based on what you described, this looks more like a typical RMII clocking issue than a problem in the Eth_43_GMAC TX/RX software flow.

At first, Please check that the external RMII 50 MHz clock is present and stable before calling Eth_43_GMAC_Init(). This is an important point for S32K344 RMII setups.

Regarding your questions:

1. Yes - in RMII mode, it is expected that the clock configuration shows EMAC_MII_RMII_TX = 50 MHz while the internal EMAC0_RX_CLK and EMAC0_TX_CLK are derived as 25 MHz. 

2. No - emac_mii_rx_clk is not used by the S32K344 EMAC in RMII mode. In the usual S32K3 RMII setup, the PHY provides the 50 MHz TX clock to the MAC and the internal EMAC RX/TX clocks are derived from that clock using divider 2. 

3. On my side, I typically use only the RMII selection in DCMRWF1 as the key additional setting, usually as the very first row in the project:

IP_DCM_GPR->DCMRWF1 = (IP_DCM_GPR->DCMRWF1 & ~DCM_GPR_DCMRWF1_MAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_MAC_CONF_SEL(2U);

4. The PHY clocking part is still not fully clear from your description. Saying that the KSZ8091RND receives 50 MHz on XI does not automatically confirm that the S32K344 MAC is receiving the required 50 MHz RMII reference clock on emac_mii_rmii_tx_clk. Please confirm how exactly the 50 MHz RMII reference clock is connected between the PHY / oscillator and the MCU and ideally share that portion of the schematic.

5. For CRC error + dribble error on RX, I would check the RMII clocking/signals in this order:

REF_CLK / RMII_TX_CLK (50 MHz)
CRS_DV
RXD0 / RXD1
RX_ER

6. I'm not aware of an official NXP example specifically for S32K344 + KSZ8091RND + RMII + no lwIP. However, you may refer to this S32K344 EMAC example and compare your clock/pin setup against it, or adapt it to your board:

Example S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0

As an additional debug step, if your PHY supports it, please also try enabling MII/RMII loopback on the PHY side so that the MAC can receive back frames that it transmitted. This can help separate a PHY/link-level problem from an MCU RX sampling problem.

Best regards,

Pavel

[brunoGT88]

Hello Pavel,

Thank you for your reply and guidance.

We performed additional hardware and software checks following your points.

First, we confirmed with an oscilloscope that the 50 MHz RMII clock is present and stable at the MCU pin configured as emac_mii_rmii_tx_clk, which is PTC0. We also confirmed that this clock is present before the Ethernet driver initialization.

Regarding the emac_mii_rx_clk signal, we understood your explanation that it is not used in RMII mode on the S32K344. We removed this signal from the configuration to avoid confusion, but the error behavior did not change.

We also checked DCMRWF1. The RTD driver is configuring RMII mode with MAC_CONF_SEL = 2U, as you mentioned.

During schematic and board inspection, we found a hardware issue: resistor R190, which connects the PHY CRS_DV signal to the MCU pin, was open/not mounted. This signal corresponds to the RMII CRS_DV signal, connected to the MCU pin configured as emac_mii_rmii_rx_dv.

After identifying this, we mounted/closed resistor R190. After that, the CRS_DV signal started appearing on the oscilloscope and now toggles at the MCU pin during reception. We also measured RX_ER, and it remains low all the time, with no pulses during the frame.

Even after fixing CRS_DV, the issue remained. The driver still reports ErrMask = 0x01080000, which means CRC_ERROR + DRIBBLE_ERROR.

We also checked the RX buffer content. The frame seems to reach the GMAC, but some bytes are received with incorrect bits. For example, the expected frame was:

Destination MAC: 02:00:00:00:00:02
Source MAC: 11:12:21:77:77:77
EtherType: 88:88

But what appeared in the RX buffer was something like:

Destination MAC: 21:00:00:00:00:02
Source MAC: 11:21:11:76:77:77
EtherType: 8B:88

After that, a byte 08 appeared, and then the remaining bytes were zero.

This suggests that the frame is reaching the GMAC, but the data is being sampled with incorrect or misaligned bits.

We also observed CRS_DV on the oscilloscope. At the end of the frame, when it goes low, it toggles for a few cycles before becoming definitively low. From our understanding, this behavior may be normal in RMII because CRS_DV combines CRS and RX_DV, but we would like to confirm if this is expected with the S32K344/GMAC.

After that, we reviewed the board again and confirmed that the resistors/jumpers for the remaining RMII signals are mounted correctly. After the issue found on R190, we also reviewed the other RMII signals and did not find any other missing or open resistors.

We also implemented a loopback test on the KSZ8091RND PHY. We configured the PHY through MDIO for loopback in the Basic Control register. In the debugger, we confirmed that the bits are:

loopback = 1
speedSelect = 1
autoNegotiationEnable = 0
duplexMode = 1

So the PHY is in loopback mode, 100 Mbps, full-duplex, with auto-negotiation disabled.

In this mode, our software transmits a frame through the GMAC and immediately polls for reception using Eth_43_GMAC_Receive. The TX sequence still confirms correctly with Eth_43_GMAC_TxConfirmation.

Even with the PHY in loopback mode, the issue remains. The frame still reaches the RX buffer, but with corrupted bytes, and the driver still reports ErrMask = 0x01080000, which means CRC_ERROR + DRIBBLE_ERROR.

This seems to remove the cable and the other device from the analysis, since the issue also happens on the local path MCU -> PHY -> internal PHY loopback -> MCU.

Currently, our answers to your points are:

1->We confirmed that EMAC_MII_RMII_TX = 50 MHz and that EMAC0_RX_CLK / EMAC0_TX_CLK = 25 MHz seem to be normal in RMII.

2->We confirmed that emac_mii_rx_clk is not required in RMII. It was removed from the configuration, but the issue continued.

3->We confirmed that the driver configures DCMRWF1.MAC_CONF_SEL = 2U.

4->We confirmed with an oscilloscope that the 50 MHz clock reaches the MCU pin PTC0 / emac_mii_rmii_tx_clk.

5->We confirmed that CRS_DV now reaches the MCU after mounting/closing resistor R190.

6->We confirmed that RX_ER remains low all the time during reception.

7->We confirmed that PHY loopback is really active according to the BMCR readback.

8->We confirmed that the resistors/jumpers for the remaining RMII signals are mounted correctly.

Even so, we are still receiving frames with corrupted bytes and CRC_ERROR + DRIBBLE_ERROR.

In this scenario, the issue still seems related to the local RMII interface between the S32K344 and the KSZ8091RND, possibly timing/skew between REF_CLK, TXD0/TXD1/TX_EN, CRS_DV and RXD0/RXD1, or some electrical/pad configuration of the RMII signals.

Do you have any specific recommendation for this case, now that the error also occurs with PHY loopback enabled? Is there any pad configuration, clock phase, drive strength, slew rate, or series resistor requirement for RMII on the S32K344 Mini EVB that we should verify?

Is there also any recommended GMAC or PHY test to separate whether the issue is on the TX RMII path from the MCU to the PHY or on the RX RMII path from the PHY to the MCU?

Thank you in advance for your support and guidance.

[brunoGT88]

I'm using RTD 5.0.0.

[brunoGT88]

Hello Pavel,

We have one important update.

We enabled the internal MAC loopback on the S32K344 and adjusted our test so it only performs TX followed by RX, without enabling PHY loopback and without waiting for PHY link-autonegotiation.

With MAC internal loopback, the test passes correctly. The received frame is valid and there are no CRC or dribble errors.

However, with KSZ8091RND PHY loopback enabled, the issue remains: the frame reaches the RX buffer, but some bytes are corrupted and the GMAC reports CRC error.

So the current result is:

MAC internal loopback: OK, no CRC-dribble error
PHY loopback: FAIL, CRC error remains
Normal external RX: FAIL, CRC error remains

This seems to indicate that the GMAC driver, TX-RX software flow, buffers, and internal MAC path are working correctly, and that the remaining issue is likely on the external RMII path between the S32K344 and the KSZ8091RND, or in the PHY-RMII-pad configuration.

Do you have any recommendation for what to check next, considering that MAC internal loopback passes but PHY loopback fails?

Thank you.

[brunoGT88]

Hello @PavelL,

We have an important new finding.

We tested the board TX using Wireshark on the PC. The firmware sends frames with:

Destination MAC: 70:69:79:A6:74:4F
Source MAC: 11:12:21:77:77:77
EtherType: 0x8888
Payload: 0x55 pattern

However, Wireshark shows that the frames arriving at the PC are already corrupted. The source MAC, destination MAC, and EtherType are not correct.

So the issue is not only on RX into the S32K344. The TX path from the S32K344 to the PHY-PC is also corrupting bits.

MAC internal loopback still works correctly, so the frame is built correctly inside the GMAC. The corruption appears when the frame goes out through the external RMII interface.

This now points more strongly to the external RMII TX path or pad configuration:

TXD0
TXD1
TX_EN
REF_CLK - RMII_TX_CLK

Do you recommend any specific pad settings for RMII TX on S32K344, such as drive strength, slew rate, keeper, or pull configuration? Currently the generated pin configuration shows driveStrengthEnable disabled for TXD0, TXD1, TX_EN, and TX_CLK.

Thank you.

[PavelL]

Hello @brunoGT88 ,

Thank you for the detailed update and for performing the additional checks. Your latest results are very helpful. Since: MAC internal loopback passes, PHY loopback still fails and
the frame is already corrupted on TX when observed on the PC - this strongly suggests that the issue is not in the GMAC driver flow, buffer handling or internal MAC path.

The remaining suspect area is the external RMII interface between the S32K344 and the KSZ8091RND, including signal routing, pin mapping, I/O voltage compatibility or timing / signal integrity on the RMII lines. Please kindly review my suggestions:

• Verify I/O voltage compatibility between the KSZ8091RND and the S32K344 RMII pins.
• Check pin-to-pin continuity and signal mapping for all RMII lines.
• Confirm that TXD0/TXD1 and RXD0/RXD1 are not swapped anywhere on the board.
• Probe the RMII TX interface directly at the PHY pins (REF_CLK, TX_EN, TXD0, TXD1).
• Reconstruct the transmitted frame from the RMII TX signals and compare it with the expected frame.
• Recheck the PHY strap configuration and confirm the intended RMII / reference clock mode after reset.

Best regards,

Pavel