ESP32 Forum

• The MDI-side link initializes correctly and autonegotiates with my Ethernet switch.
• The MDIO/SMI interface is functional and I am able to read/write/dump registers via a custom command.
• The PHY is correctly outputting a 50MHz sinusoidal waveform (via attached 25MHz crystal). If I intentionally misconfigure the PHY clock then this waveform halts.
• REF_CLK from the PHY is connected to GPIO 0, which is the only GPIO which supports clock input.
• The MAC is configured with:

  Code: Select all

  #define ETHERNET_PHY_TXCLK_GPIO 0
  
  interface = EMAC_DATA_INTERFACE_RMII
  clock_config.rmii.clock_mode = EMAC_CLK_EXT_IN
  clock_config.rmii.clock_gpio = ETHERNET_PHY_TXCLK_GPIO

• A custom ping command I wrote shows no errors but no frames actually egress the device. I have added debug to LWIP and friends, this actually gets stuck at the first ARP request which is consistent with the MAC not passing traffic.

cmd_smi_do_read: EMACCONFIG_REG=0x0000CC0C, EMACDEBUG_REG=0x00000000
cmd_smi_do_read: EMACCSTATUS_REG=0x00000000, EMACWDOGTO_REG=0x00000000
cmd_smi_do_read: EMAC_EX_CLKOUT_CONF_REG=0x00000024, EMAC_EX_OSCCLK_CONF_REG=0x01001253, EMAC_EX_CLK_CTRL_REG=0x00000001
cmd_smi_do_read: EMAC_EX_PHYINF_CONF_REG=0x00008000, EMAC_PD_SEL_REG=0x00000000

ESP_ondrej wrote: I checked the internal documentation and this EMACCSTATUS_REG register is optional and is present only when the MAC is configured for the SGMII, RGMII, or SMII PHY interface. Therefore you cannot get correct data from it when in RMII mode.

ESP_ondrej wrote: For link status, please monitor `ETHERNET_EVENT_CONNECTED` in event handler you register during initialization.

ESP_ondrej wrote: For further debugging, try to switch PHY to loopback mode. You need to write simple application. The best approach is to not use LwIP for this. Just initialize Ethernet without ESP-NETIF init and register your own Rx callback function using `esp_eth_update_input_path`. Then check with oscilloscope if you see some signal between PHY and ESP on RMII Tx/Rx pins.

I do see this event fire in my logs so it appears this is working. Just for my own edification, what does this event specifically signify?

ESP_ondrej wrote: It signify that link between KSZ8081 and your PC was negotiated and is up, i.e. PHY MDI link status, check details here. In any case, this tells you that the PHY is able to communicate with its counterpart (the PC) and that PHY MII Management Interface (MDC/MDIO) is functional. However, it seems there might be issue with RMII data path.

ESP_ondrej wrote: I don't think it is needed to get much deeper into EMAC, the driver driver should be stable enough. You can try to increase debug log in EMAC driver to see, if you receive any data (https://github.com/espressif/esp-idf/bl ... esp.c#L243). If I were you, I would focus at the RMII data path at this point (check it is correctly connected and if signal is present). For example, I have experience that the PHY was able to communicate with the ESP32 in one way only. The root cause turned out to be fallen/not assembled termination resistor on RMII data path. Issue one wouldn't expect

• I enabled remote (analog) loopback on the PHY; I do see broadcast pings from my test host returned. Given this, I am comfortable saying the MDI-side link is just fine.
• I enabled local (digital) loopback on the PHY; unfortunately pings to my local IP are always returned, even after I disable this loopback. I am calling this one a push as I suspect either LWIP or the MAC driver layer is performing the loopback in software and I haven't yet had time to write a direct Ethernet initialization and RX callback test shim yet.
• I probed RXD[1] and TXD[0] pins while sending bidirectional traffic. Unfortunately, my personal scope setup is somewhat modest and I don't have a differential probe so, really, all I am looking for is structure in the data. And structure I do find, see attached waveforms. Given this, I am fairly certain that RMII is functioning as expected.
• I looked into that log print in emac_esp32_receive your previous message. In the interest of expedience, I just switched it to an ESP_LOGE call rather than enabling full debug logs (which is going to be my next test). Unfortunately, I never see this message printed.
• I tried adding a print to emac_isr_default_handler with the goal of observing TX / RX interrupts and the DMA ring in general but I never see my print hit. This seems like nonsense since I DO receive ARP requests from the ESP32 on my dev machine (which sends an ARP reply which is never fully received by the ESP causing the next ping cycle to start with another ARP request). Given that TX seems to be working fine I think I must be missing something in my test methodology, though I couldn't find any other promising ISRs in the MAC layer that read from the DMA status register.

I enabled local (digital) loopback on the PHY; unfortunately pings to my local IP are always returned, even after I disable this loopback. I am calling this one a push as I suspect either LWIP or the MAC driver layer is performing the loopback in software and I haven't yet had time to write a direct Ethernet initialization and RX callback test shim yet.

I tried adding a print to emac_isr_default_handler with the goal of observing TX / RX interrupts and the DMA ring in general but I never see my print hit. This seems like nonsense since I DO receive ARP requests from the ESP32 on my dev machine (which sends an ARP reply which is never fully received by the ESP causing the next ping cycle to start with another ARP request). Given that TX seems to be working fine I think I must be missing something in my test methodology, though I couldn't find any other promising ISRs in the MAC layer that read from the DMA status register.