English is currently available.
Ethernet DISCUSSION
I connected a LAN8720 breakout to an ESP32 over RMII. When I plug in the cable the link LED on the jack lights and the switch shows a 100 Mbit/s link, but the firmware either reports that the PHY was not found or starts and never gets an address by DHCP. Wiring is by jumper wires about 10 cm long.
What does a lit link LED actually prove, and what are the usual causes of an RMII interface that links but passes no traffic?
The link LED proves less than it seems. The PHY negotiates and maintains the link entirely by itself, using its own clock and the cable side. It will show a link with the MAC interface completely disconnected. So you have confirmed the PHY's power, its clock and the magnetics, and nothing about the RMII data lines, the 50 MHz reference seen by the MAC, or the management bus.
Split the problem in two. "PHY not found" is a management-bus failure: MDC, MDIO, the PHY address or reset. Starting without ever completing DHCP is a data-path failure: the reference clock or the RMII signals.
For the management side, the driver must use the address the board is strapped to. The LAN8720 takes its address from a strap pin sampled at reset, giving address 0 or 1, and common breakout boards are wired for address 1 while many examples default to 0. Read PHY registers 2 and 3: a LAN8720A returns 0x0007 and a value of the form 0xC0Fx. All ones (0xFFFF) means nothing answered at that address.
Also check that MDIO has its pull-up, that MDC and MDIO are on the GPIOs the firmware is configured for, and that the PHY's reset pin is released and not left floating. If the board has a reset or power-enable input, the firmware has to drive it before it probes the PHY.
The 50 MHz reference clock is the usual data-path culprit, and the ESP32 has particular rules. The RMII data pins are fixed (TXD0 on GPIO19, TXD1 on GPIO22, TX_EN on GPIO21, RXD0 on GPIO25, RXD1 on GPIO26, CRS_DV on GPIO27), and the clock is either fed in on GPIO0 from an external 50 MHz source or generated by the ESP32 and output on GPIO16 or GPIO17. The firmware's clock mode setting must match what the hardware does.
Breakouts with a 50 MHz oscillator drive the clock into GPIO0, which is also a boot strapping pin. If the oscillator is running during reset it can stop the chip from booting or from entering download mode, which is why proper designs control the oscillator's enable pin from a GPIO and switch it on only after boot.
Ten-centimetre jumper wires are marginal at these speeds. A 50 MHz clock has a 20 ns period, and RMII data must be valid for a few nanoseconds either side of the clock edge; long unshielded wires with no nearby ground add ringing and skew and couple the clock into neighbouring data wires. The typical result is exactly yours: link up, a trickle of corrupted frames, DHCP never completing.
Shorten the wires to a few centimetres, run a ground wire next to the clock, and if possible move to a board where the PHY is on the same PCB. On a PCB, keep RMII traces short and of similar length over a ground plane. To confirm the data path, watch the MAC's receive and CRC error counters while other hosts broadcast on the network; rising CRC errors mean the signals are arriving but corrupted.
