EnglishEthernet
Why does the Ethernet LED on WT32-ETH01 stay off after power-on and cable insertion?
The Ethernet PHY on WT32-ETH01 uses an independent external crystal. The crystal enable pin is connected to ESP32 GPIO16.
If GPIO16 is not pulled high during power-on or initialization, the PHY will not receive its clock, so the Ethernet port cannot work normally and the Ethernet LED will not turn on.
Pull GPIO16 up to 3.3 V so it is high by default at power-on. Only when the PHY crystal is running correctly can the Ethernet port establish a physical link and turn on the LED. Otherwise, Ethernet initialization and communication will fail.
Can Wi-Fi and Ethernet be used at the same time on an ESP32 module?
Yes, Wi-Fi and Ethernet can be used at the same time on an ESP32 module, but when Ethernet and Wi-Fi are used together, an external PHY or external clock source must provide the RMII REF_CLK.
In RMII mode, the Ethernet MAC and PHY require a shared 50 MHz synchronous clock. If Ethernet and Wi-Fi are used at the same time, the RMII clock should not be generated by the ESP32 internal APLL, because that may cause clock instability.
If the internal APLL is used to generate RMII REF_CLK, Wi-Fi must be disabled.
Which Ethernet controller chips are currently supported on ESP32-S3? Can other models be adapted with a custom driver?
ESP-IDF currently provides driver support for several SPI Ethernet controllers on ESP32-S3. Common supported SPI models include DM9051, W5500, KSZ8851SNL, ENC28J60, CH390, and LAN865x.
Espressif also provides the unified ethernet_init component, which allows these SPI Ethernet chips to be selected from menuconfig and simplifies initialization.
Other Ethernet chips can also be adapted in principle. The ESP-IDF Ethernet driver framework provides the esp_eth_phy_t and esp_eth_mac_t abstraction interfaces, so developers can implement a custom driver based on that framework. Note that third-party chips are usually outside Espressif's official validation scope, so custom adaptation and maintenance are the developer's responsibility.
After increasing the Ethernet netif priority in ESP-IDF, why does an existing TCP connection still communicate through the Wi-Fi address after the cable is inserted?
When a socket is created in the ESP-IDF TCP/IP stack and the application does not explicitly bind it to a specific netif, the connection uses the default netif with the highest priority at that time.
If the TCP connection was created when only Wi-Fi was available, the socket is already bound to the Wi-Fi interface. Even if Ethernet later comes up and becomes the new default netif, the existing TCP connection will not migrate automatically and will keep using the Wi-Fi path.
To switch the connection to Ethernet, disconnect the existing connection and create a new one after the Ethernet interface is ready and has become the default netif. The new connection will then use the current highest-priority default netif.
For precise routing in a multi-netif design, explicitly bind the socket to the target network interface instead of relying only on default netif priority changes.
When running the ethernet/basic example on a WT01P4C5-S1-N16R32 module, cable insertion is detected but DHCP cannot obtain an IP address and ping fails. What is the cause?
ESP32-P4 GPIO35 is internally pulled up by default, and the WT01P4C5-S1-N16R32 module already integrates an external 10 kΩ pull-up resistor on GPIO35.
If another pull-up resistor is added externally on the module, the additional load can interfere with the RMII TXD1 signal on this pin and cause abnormal data transmission. The result can be that cable insertion is detected, but DHCP receives no response, no IP address is obtained, and the router cannot be pinged.
Check the external circuit and remove any extra pull-up resistor on GPIO35. The integrated 10 kΩ pull-up on the module is sufficient.
