eth2ap gets ethernet link down and up repeatedly

[zhouzhendong]

On a custom board with ESP32-D0WDQ6-V3 + RTL8201, PHY ref clock 50M is fed from ESP32 GPIO0. I can run ethernet_iper without issue.
But when I tried eth2ap, I always get Ethernet link up and down repeatedly. In particular, when I tried to connect a WiFi client to the AP, Ethernet link drops immediately.
This looks like a symptom that WiFi causes some interference on the clock line. But I am not sure.
My understanding is the 50M ref clock is from APLL while WiFi uses APB_CLK/PLL_CLK. They should not affect each other.
Changing to an external crystal or feed clock from PHY to ESP32 might be the way to go. But I do want to understand the root cause before moving on.
Thanks in advance.

[flyingcrab]

Hi, I'm having the same problem with almost the same setup, just using IO17 for the clock instead. I've tested with wifi sta and ap modes and both make the ethernet disconnect.
Have you tested using an external oscillator? Or found what the issue was?

[ESP_ondrej]

Using APPL CLK directly on the GPIO0 as a source for RMII REF CLK is experimental feature. There was really an issue observed when used along with WiFi under high traffic.

This is documented in the Ethernet Configuration menu, please see below:

GPIO0 can be set to output a pre-divided PLL clock (test only!).
Enabling this option will configure GPIO0 to output a 50MHz clock.
In fact this clock doesn't have directly relationship with EMAC peripheral.
Sometimes this clock won't work well with your PHY chip. You might need to
add some extra devices after GPIO0 (e.g. inverter).
Note that outputting RMII clock on GPIO0 is an experimental practice.
If you want the Ethernet to work with WiFi, don't select GPIO0 output mode for stability.

[flyingcrab]

I see. Is outputting the RMII clock from ESP an experimental feature on all pins or only on IO0? On menuconfig it seems to state that's only the case for IO0. I'm using IO17 and having disconnects when wifi is enabled

[ESP_ondrej]

GPIO17 should not be that much affected. However, a PCB design may affect that and PHY chip's robustness is also another side. Different behavior might be observed with different PHY chips. There might be incorrect phase shift in CLK or other issues with signal integrity... You can try to use GPIO16, the CLK at this pin have different phase. Unfortunately, I cannot give you better answer since it is more question for HW engineers... You can check discussion here (https://electronics.stackexchange.com/q ... thernet-ph) to see that handling the RMII CLK really might be tricky.

[kukri_yuryy]

Has anyone solve the link up/down problem when turning on wi-fi?

The previous project was on LAN8720 and ESP 32, there were no problems, the device worked both by wire and by wifi simultaneous.

In the new version of the project, I use RTL8201F and with wifi turned on, link up/down constantly. I switch RMIICLK from IO17 to IO16, it only got worse.

Best regards, Yuri

[kukri_yuryy]

I have next situation.
My previous project on ESP32 + LAN8720 works stably with Wi-Fi and wired Ethernet simultaneously.
The new project on RTL8201 + ESP32 does not work stably when both interfaces enabled.
The wired interface is constantly Link Up/Link Down. WiFi ping delay from 500ms to 1,5s and does not work normally.
But if uncheck one of the interfaces in the project settings, the second one works stably. I use ESP-IDF. RMII clock internal IO17

[chrismisztur]

We have observed that if you force the network to 10Mbit this is no longer an issue. Is it the same for you?

[TheSeven]

I just ran into the very same issue.

As expected this is NOT related to which pin sources the RMII interface clock, because this is not an issue at the RMII interface level in the first place, but one of the main clock source used for the PHY. I.e. RMII phase alignment issues can only cause packet loss, but not loss of link, which is what we're seeing here.
Disabling Wifi resolves this, and using the RTL8201F Xtal oscillator as its main clock source does as well, even if the ESP32 continues to be the RMII interface clock source, and even if that is provided through GPIO0.

The clock signal provided by the ESP32 to the PHY looks just fine on a scope, frequency is also within tolerance, at least on average.
I suspect that this is some kind of phase noise or jitter issue where Wifi activity somehow affects the APLL's output. Difficult to catch on a scope because it's a rare event that you can't really trigger on.
Are there any tunables on the APLL that we may want to try playing with? I'm afraid this looks like it will need a hardware workaround (i.e. ESP32 just can't be used as the PHY clock source if Wifi is being used at the same time).
Someone should adjust the help text in Kconfig to reflect that this is NOT a GPIO0 related issue, but one that affects RMII clock output mode in general.

[martins]

Could also consider using external oscillator as clock source for both ESP32 and ethernet PHY. I had issues when using ESP32 or LAN8720 as clock source, but external oscillator works reliably.