LAN8720 Packet loss of ESP32 external crystal

[hzhh110]

Board

ESP32

Device Description

When I used the network cable mode and the external crystal oscillator, I found that the LAN8720 inch was losing packets.
The internal ETH _ CLOCK _ GPIO17 _ OUT crystal oscillator is normal, while the external crystal oscillator is connected to the network cable smoothly. The internal crystal oscillator may not be connected to the network cable easily

Is there any way to process the external crystal oscillator with software

Hardware Configuration

LAN8720 using external crystal and using GPIO17 have two different performances, one is the connection problem, the other is the packet loss problem

Version

latest master (checkout manually)

IDE Name

Platformio

Operating System

Mac0S

Flash frequency

40Mhz

PSRAM enabled

yes

Upload speed

115200

Description

LAN8720 using external crystal and using GPIO17 have two different performances, one is the connection problem, the other is the packet loss problem

Sketch

ping 192.168.18.60

Debug Message

64 bytes from 192.168.18.61: icmp_seq=388 ttl=255 time=2.821 ms
64 bytes from 192.168.18.61: icmp_seq=389 ttl=255 time=9.245 ms
64 bytes from 192.168.18.61: icmp_seq=390 ttl=255 time=7.420 ms
64 bytes from 192.168.18.61: icmp_seq=391 ttl=255 time=8.920 ms
64 bytes from 192.168.18.61: icmp_seq=392 ttl=255 time=2.668 ms
64 bytes from 192.168.18.61: icmp_seq=393 ttl=255 time=9.134 ms
64 bytes from 192.168.18.61: icmp_seq=394 ttl=255 time=8.936 ms
64 bytes from 192.168.18.61: icmp_seq=395 ttl=255 time=8.170 ms
64 bytes from 192.168.18.61: icmp_seq=396 ttl=255 time=9.170 ms
64 bytes from 192.168.18.61: icmp_seq=397 ttl=255 time=9.129 ms
64 bytes from 192.168.18.61: icmp_seq=398 ttl=255 time=8.786 ms
64 bytes from 192.168.18.61: icmp_seq=399 ttl=255 time=8.957 ms
64 bytes from 192.168.18.61: icmp_seq=400 ttl=255 time=2.904 ms
64 bytes from 192.168.18.61: icmp_seq=401 ttl=255 time=9.138 ms
Request timeout for icmp_seq 402

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[hzhh110]

[hzhh110]

[hzhh110]

#define ETH_ADDR 1
#define ETH_POWER_PIN -1
#define ETH_MDC_PIN 23
#define ETH_MDIO_PIN 18
#define ETH_TYPE ETH_PHY_LAN8720
#define ETH_CLK_MODE ETH_CLOCK_GPIO17_OUT

[hzhh110]

ETH.begin(ETH_ADDR, ETH_POWER_PIN, ETH_MDC_PIN, ETH_MDIO_PIN, ETH_TYPE, ETH_CLK_MODE);

[hzhh110]

Hey, I used the Internet (Internet of Things), but I didn't lose the packet, but I lost the packet with LAN ping.

[TD-er]

What board do you use?
GPIO-16 and 17 are also used for PSRAM, so you have to make sure PSRAM support is disabled or else polling may perhaps offset your Ethernet clock?

[TD-er]

Just some other idea, inspired by this PR for Olimex boards: #9623
Maybe you can also experiment with setting the GPIO drive capability (drive strength) when using ESP generated clock.

[hzhh110]

I use the external 50Mhz crystal calibrator to provide the GPIO0 and LAN8720 < ETH _ CLOCK _ GPIO0 _ in > with the crystal calibrator at the same time. The communication is good in the network cable mode, but it will enter the download mode randomly when it is powered on. How to deal with this?It is found that the power-on probability may fail to obtain the chip or the URL by using the ETH _ CLOCK _ GPIO0 _ OUT, the ETH _ CLOCK _ GPIO16 _ OUT, and the ETH _ CLOCK _ GPIO17 _ OUT
Want to know how to deal with the ETH _ CLOCK _ GPIO0 _ in to solve the problem of probability entering the download mode?

[TD-er]

Ah that's a different problem.
You 'simply' need to decouple the clock from GPIO-0 before boot.
On some crystals there is an enable pin. Maybe you can route some GPIO pin from the ESP to this pin if present?
Other solution can be to add some analog switch to route the 50 MHz signal to a not connected pin of the switch and only to GPIO-0 when you enable it via some GPIO of the ESP after boot. (e.g. connect this switch to the Ethernet power pin)

[hzhh110]

Ah that's a different problem. You 'simply' need to decouple the clock from GPIO-0 before boot. On some crystals there is an enable pin. Maybe you can route some GPIO pin from the ESP to this pin if present? Other solution can be to add some analog switch to route the 50 MHz signal to a not connected pin of the switch and only to GPIO-0 when you enable it via some GPIO of the ESP after boot. (e.g. connect this switch to the Ethernet power pin)

Thank you for your reply. It's a little embarrassing. I don't know where to start. Now there are only IO ports GPIO1 (TX), GPIO3 (RX) and GPIO36 and GPIO39. Of course, there is a red light (GPIO17) that can switch with GPIO1 (TX), but I don't know how to decouple GPIO0.Can you be more specific?

[TD-er]

This is how I did it on a board I made which is using those Ali Express LAN8720A chips (with 2x7 pin header)

The chip I used is TS5A3157DCKR
The default path of the signal is from the NC to COM (or vice-verse as it is just an analog switch, but that's not used here)
When V_LAN is present, the signal will be from NO to COM.

Just consider it to act like a relay, but then capable of switching faster and also perfectly capable of transporting 50 MHz signal from the crystal.

[hzhh110]

The chip I used is TS5A3157DCKR The default path of the signal is from the NC to COM (or vice-verse as it is just an analog switch, but that's not used here) When V_LAN is present, the signal will be from NO to COM.

Just consider it to act like a relay, but then capable of switching faster and also perfectly capable of transporting 50 MHz signal from the crystal.

Thank you very much

[Jason2866]

Closing since not an issue from Arduino core.