cancel
Showing results for 
Search instead for 
Did you mean: 

Ethernet received packets discarded after being flagged as dribble error in RMII mode

RConf.1
Associate II

We are developing a single pair ethernet board using STM32H725VG as MCU and DP83TD510E (Texas Instruments) as PHY. MCU and PHY are interfaced through RMII mode (10Mbps).

When we run our application, the problem is that MCU drops some ethernet packets received through RMII. Looking at the ethernet Rx descriptor RDES3, we notice the related ethernet packets are discarded because bit 15 (error summary field) and bit 19 (dribble bit error) of RDES3 are set to 1, while at the same time bits 20, 21, 22, 23, 24 are always zero. Since the MCU reference manual (RM0468 Rev 3) says that dribble bit error is valid only in the MII Mode, we would like to ask you if it is correct to discard received packet flagged as dribble error (in RMII mode) or if they should be forwarded to the system.

Thank you for your help.

Kindly,

Riccardo

2 REPLIES 2
Piranha
Chief II

ES0491 - Rev 7:

2.20.10 Packets dropped in RMII 10Mbps mode due to fake dribble and CRC error

Though it states that the CRC error is also set... Note that CE (24) bit is only valid if the LD (28) bit is also set in RDES3.

RConf.1
Associate II

Hello Piranha,

thank you for your answer.

As you said, errata sheet states that: "When operating with the RMII interface at 10 Mbps, the Ethernet peripheral may generate a fake extra nibble of data repeating the last packet (nibble) of the data received from the PHY interface. This results in an odd number of nibbles and is flagged as a dribble error. As the RMII only forwards to the system completed bytes of data, the fake nibble would be ignored and the issue would have no consequence. However, as the CRC error is also flagged when this occurs, the error-packet drop mechanism (if enabled) discards the packets" 

Our situation is a little bit different, in Rx descriptor RDES3 we have:

  • DE (19) bit set to 1
  • LD (28) bit also set to 1
  • CE (24) always 0

That's why even if we implement the workaround described in ES0491 - Rev 7, we get no solution to our problem.

Let me know if you have any suggestions.

Thanks again,

Riccardo