Settings for the RMII clock and the PHY reset

[imfatant]

Hi,

I have a WT32-ETH01 clone. Seem to be a lot of these knocking about.

I'm using the ESP-IDF api with Visual Studio Code as my IDE, and mostly I can see how to configure things such that they appear to be working. I am, however, confused about the settings for the clock and the PHY reset. Here's how I have it at the moment:

From a hardware point of view, we essentially have the ESP32 SoC, an oscillator (marked 50.0 MHz on my board) and the built-in LAN8720 chip.

1) You can see here that I've got RMII clock mode set to Input from external. What I think this means is that the RMII interface is run off the 50.0 MHz "external" oscillator on the board. Is that correct? If so, this seems logical to me. Why else would there be a 50.0 MHz oscillator sitting right there on the board? I see in your configuration, however, that you Output from internal clock on GPIO 16. Can you please explain why you do this? Where does the clock signal come from in this case, and where exactly is it going? And why do this rather than selecting the Input from external option?

2) Then there is the PHY reset GPIO pin. I really am quite in the dark about this. If I set it to GPIO 16, and run the statoeth example from the ESP-IDF network examples, the code behaves one way; if I set it to -1 the code behaves another way - and I'm not certain at this stage which is correct!

Any guidance you could give me on these matters would be appreciated.

Thanks :)

[egnor]

(Wait, you have a clone of the WT32-ETH01? The original product is dirt cheap already, I'm surprised anyone is cloning it!)

1. I think you're misreading my code slightly? It actually does get the clock from an external input:

   mac_config.clock_config.rmii.clock_mode = EMAC_CLK_EXT_IN;
   mac_config.clock_config.rmii.clock_gpio = EMAC_CLK_IN_GPIO;
   mac_config.smi_mdc_gpio_num = 23;
   mac_config.smi_mdio_gpio_num = 18;

The reference to GPIO 16 is actually just setting that GPIO high, which enables that external clock:

ESP_ERROR_CHECK(gpio_set_direction(GPIO_NUM_16, GPIO_MODE_OUTPUT));
ESP_ERROR_CHECK(gpio_set_level(GPIO_NUM_16, 1));

2. In the schematic I have, at least, the PHY reset pin is pulled high and not connected to any GPIO on the ESP32, which is why I set it to -1. I think some people configure the PHY reset as pin 16, which is the external-clock-enable pin (as described above), because they know doing so will cause the driver to drive that pin high. But that seems like a silly and unnecessary and unclear hack to me, I'd rather just set the GPIO high directly and not configure a reset pin, since there isn't actually a reset pin (bringing GPIO 16 to LOW will just shut off the oscillator, won't actually reset the PHY).

Does that all make sense??

[imfatant]

Makes perfect sense, and has cleared up a lot of things. Thanks for taking the time to reply.

Things are working quite well now (with the ESP-IDF statoeth example). Incidentally, I was getting a lot of buffer overrun errors (the example code repeatedly printed esp.emac: emac_esp32_transmit(229): insufficient TX buffer size). Enabling CONFIG_ETH_TRANSMIT_MUTEX and increasing the Ethernet DMA buffer size to 1024 bytes seems (so far) to have eliminated them. Will have to investigate further...

There is something here: https://github.com/platformio/platform-espressif32/issues/1309

[egnor]

That's odd, assuming you're not using threads yourself I wouldn't expect CONFIG_ETH_TRANSMIT_MUTEX to be needed.

I haven't run into this error myself, despite using dozens of these in production, but I'm pretty much only doing low bandwidth command-and-control messaging over MQTT, so that might be why I dodged that particular issue. In any case it doesn't seem to be related to this particular hardware?

In any case I'll update the main README of this page to be a little more explicit about the pin usage.

[egnor]

I use the Arduino runtime! So I think you'll find the sdkconfig in the arduino-esp32 repo.