No ethernet PHY connectivity with ESP-32-WROOM

[GeorgeOfTheJungle]

No I have not been messing with the MAC address. The serial monitor reads: 24:0A:C4:23:FC:27

That's a good MAC. This is interesting:

A normal MAC address looks like this: 00:09:5B:EC:EE:F2. It is composed of six octets. The first half (00:09:5B) of each MAC address is known as the Organizationally Unique Identifier (OUI). Simply put, it is the card manufacturer. The second half (EC:EE:F2) is known as the extension identifier and is unique to each network card within the specific OUI. Many access points will ignore MAC addresses with invalid OUIs. So make sure you use a valid OUI code when you make up MAC addresses. Otherwise, your packets may be ignored by the Access Point. The current list of OUIs may be found here. Make sure that that the last bit of first octet is 0. This corresponds to unicast addresses. If it is set to 1, this indicates a group address, which is normally exclusively used by multicast traffic. MAC addresses with a source set to multicast are invalid and will be dropped. Examples of valid OUIs: 00:1B:23, 08:14:43, AA:00:04 because 0, 8 and A are even Examples of invalid OUIs: 01:1B:23, 03:23:32

(http://www.experts123.com/q/what-is-the-format-of-a-valid-mac-address.html)

Code: [Select]

(192.168.1.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]

That's ok.

[padagra]

Good to know. I just had some dinner but in the meantime while I'm getting captures under the microscope, this is the code I am using per your recommendations. Still using Arduino IDE:

Code: [Select]

#define ETH_CLOCK_IN_PIN                    0
 #define ETH_MDIO_PIN                       18
 #define ETH_TXD0_PIN                       19
 #define ETH_TXEN_PIN                       21
 #define ETH_TXD1_PIN                       22
 #define ETH_MDC_PIN                        23
 #define ETH_RXD0_PIN                       25
 #define ETH_RXD1_PIN                       26
 #define ETH_MODE2_PIN                      27
 #define ETH_POWER_PIN                      12
 #define ETH_ADDR                            0
 #define ETH_TYPE              ETH_PHY_LAN8720
 #define ETH_CLK_MODE     ETH_CLOCK_GPIO17_OUT

 <ETH.h>


static bool eth_connected = false;

void WiFiEvent(WiFiEvent_t event)
{
  switch (event) {
    case SYSTEM_EVENT_ETH_START:
      Serial.println("ETH Started");
      //set eth hostname here
      ETH.setHostname("esp32-ethernet");
      break;
    case SYSTEM_EVENT_ETH_CONNECTED:
      Serial.println("ETH Connected (SYSTEM_EVENT_ETH_CONNECTED)");
      break;
    case SYSTEM_EVENT_ETH_GOT_IP:
      Serial.print("ETH MAC: ");
      Serial.print(ETH.macAddress());
      Serial.print(", IPv4: ");
      Serial.print(ETH.localIP());
      if (ETH.fullDuplex()) {
        Serial.print(", FULL_DUPLEX");
      }
      Serial.print(", ");
      Serial.print(ETH.linkSpeed());
      Serial.println("Mbps");
      eth_connected = true;
      break;
    case SYSTEM_EVENT_ETH_DISCONNECTED:
      Serial.println("ETH Disconnected");
      eth_connected = false;
      break;
    case SYSTEM_EVENT_ETH_STOP:
      Serial.println("ETH Stopped");
      eth_connected = false;
      break;
    default:
      break;
  }
}

void testClient(const char * host, uint16_t port)
{
  Serial.print("\nconnecting to ");
  Serial.println(host);

  WiFiClient client;
  if (!client.connect(host, port)) {
    Serial.println("connection failed");
    return;
  }
  client.printf("GET / HTTP/1.1\r\nHost: %s\r\n\r\n", host);
  while (client.connected() && !client.available());
  while (client.available()) {
    Serial.write(client.read());
  }

  Serial.println("closing connection\n");
  client.stop();
}

void setup()
{
  Serial.begin(115200);
  WiFi.onEvent(WiFiEvent);
  ETH.begin(ETH_ADDR, ETH_POWER_PIN, ETH_MDC_PIN, ETH_MDIO_PIN, ETH_TYPE, ETH_CLK_MODE);
}


void loop()
{
 
  if (eth_connected) {
    Serial.print("I am connected");
    testClient("https://www.google.com", 80);
  }
  delay(5000);
}
Need to see how I can export the microscope images now...

[padagra]

Okay, I don't see any issues with the PCB manufacturing or shorts that immediately stand out. I merged some of the images from the microscope, see below:

[GeorgeOfTheJungle]

I have rewired my PHY to work in ETH_CLOCK_GPIO17_OUT mode, and it works sometimes yes sometimes no. Did you find the culprit?

[padagra]

No I have not found the culprit but that's also my experience with it working on and off. It's still concerning that when it does get a connection the 8710a chip starts heating up, perhaps its due to manual assembly with hobbiest grade tools?

All that aside, I have been in more communication with the wESP32 developer, Patrick. He gave a few suggestions that I am going to try tonight, I may make a couple PCB design changes and re-order a batch of boards to test everyone's concerns that is involved in helping diagnose this odd issue.

[GeorgeOfTheJungle]

I've bought one of these https://es.aliexpress.com/item/32947407343.html to tinker with the ETH_CLOCK_GPIO17_OUT mode. It works always fine in ETH_CLOCK_GPIO0_IN mode, but not when rewired and reconfigured for ETH_CLOCK_GPIO17_OUT. None of them get even warm (the other is an olimex EVB), much less hot. One thing I noticed is the amplitude of the 50MHz clock is much more than the scope was showing, because I had the 20MHz low pass filter active in that channel. It's almost 6 volts peak to peak IIRC, I don't know if that may have something to do with these faults, maybe?



Edit:
This is the schematic of that board:

[padagra]

Did you buy this to help me?? Either way you're a God send. I just bought one but on Amazon prime so I can start testing immediately, it will be here tomorrow.

That is also interesting about the 50mhz clock not being high enough voltage peak to peak, I'll re-check the clock signal and see if it it matches the spec you described.

[ttt]

Did the wESP32 developer already tell you that you need to drive NRST properly? Simply pulling it high permanently will not work and the Olimex hack with a cap does not work for a warm reset. I've been running into this issue myself in the last few days, to where the LAN8710A resets continuously.

I assume you don't care about using an extra pin, so you can make sure to drive NRST properly:

1. Pull NRST low
2. Wait for the 50mhz clock to come up (it might be already up)
3. Wait for a small period (100us worked in my case)
4. Pull NRST high

For me this makes the LAN8710a run rock solid and more importantly it can handle warm resets/debugging sessions. My code: https://github.com/tinic/lightguy/blob/master/ethernetif.cpp#L73 Code is for an STM32F107 clone, not the ESP32, so not really useful for you :-)

[GeorgeOfTheJungle]

The datasheet says:

5.3.6.1 Hardware Reset
Hardware reset is asserted by driving the nRST input low. When the nRST input is driven by an external source, it should be held LOW for at least 100 us to ensure that the transceiver is properly reset. During a hardware reset an external clock must be supplied to the XTAL1/CLKIN signal

There's no way to do that when the clock source is ETH_CLOCK_GPIO17_OUT, because there's no clock until after the call to ETH.begin(), which is a long time after /reset.

Edit:
But nRST is driven by +3.3VLAN no by the esp's /reset, so yes, if in the call to ETH.begin() the driver 1) drives ETH_POWER_PIN/PHY_PWR low to turn off +3.3VLAN then 2) enables 50MHz on ETH_CLOCK_GPIO17_OUT before 3) turning +3.3VLAN on again (ETH_POWER_PIN high) it would have the clock running before the reset, as it should.

[padagra]

Edit:
But nRST is driven by +3.3VLAN no by the esp's /reset, so yes, if in the call to ETH.begin() the driver 1) drives ETH_POWER_PIN/PHY_PWR low to turn off +3.3VLAN then 2) enables 50MHz on ETH_CLOCK_GPIO17_OUT before 3) turning +3.3VLAN on again (ETH_POWER_PIN high) it would have the clock running before the reset, as it should.

See this was my understanding as well and why I would think that the current circuit in hand should be capable of working. If the 8710a absolutely will not work unless the 50mhz clock is live before reset/power cycle (which we know to be true) then I wonder how I will occasionally (1/6 times) get a healthy connection via ethernet in the current circuit design. Granted, the chip shouldn't get hot which is another issue I have not found.

Did the wESP32 developer already tell you that you need to drive NRST properly? Simply pulling it high permanently will not work and the Olimex hack with a cap does not work for a warm reset. I've been running into this issue myself in the last few days, to where the LAN8710A resets continuously.

Yes and no. His suggestion right now is to bypass the 3.3VLAN transistors with a jumper wire directly to GPIO12 PHY POWER then probe out. He also has stated that he went down this same road basing his work off the Olimex board and had similar issues. This ultimately led him to re-do this portion of the circuit from scratch which is the design he now uses in the production version. He uses an ancillary microcontroller (PMS150C-559) to directly control the timing of the PHY reset and clock signal whereas Olimex does this all through the ESP-32.

I assume you don't care about using an extra pin, so you can make sure to drive NRST properly:

1. Pull NRST low
2. Wait for the 50mhz clock to come up (it might be already up)
3. Wait for a small period (100us worked in my case)
4. Pull NRST high

For me this makes the LAN8710a run rock solid and more importantly it can handle warm resets/debugging sessions. My code: https://github.com/tinic/lightguy/blob/master/ethernetif.cpp#L73 Code is for an STM32F107 clone, not the ESP32, so not really useful for you :-)

You are correct, I have GPIO I can spare on the ESP32. This sounds like the next step. Assuming the firmware timing is correct, I could just use the ESP32 to pull NRST low, start 50mhz clock, wait, pull NRST high. Fortunately, the board GeorgeOfTheJungle posted above should help with this as I will be able to revise faster. It will be here today.

[GeorgeOfTheJungle]

Edit:
But nRST is driven by +3.3VLAN no by the esp's /reset, so yes, if in the call to ETH.begin() the driver 1) drives ETH_POWER_PIN/PHY_PWR low to turn off +3.3VLAN then 2) enables 50MHz on ETH_CLOCK_GPIO17_OUT before 3) turning +3.3VLAN on again (ETH_POWER_PIN high) it would have the clock running before the reset, as it should.

See this was my understanding as well and why I would think that the current circuit in hand should be capable of working. If the 8710a absolutely will not work unless the 50mhz clock is live before reset/power cycle (which we know to be true) then I wonder how I will occasionally (1/6 times) get a healthy connection via ethernet in the current circuit design. Granted, the chip shouldn't get hot which is another issue I have not found.

Looking at the source code, unfortunately it seems that it enables the clock after turning on the 8710:

https://github.com/espressif/esp-idf/blob/release/v3.2/components/ethernet/emac_main.c#L1112-L1145

Code: [Select]

    emac_config.emac_phy_power_enable(true);

    //before set emac reg must enable clk
    periph_module_enable(PERIPH_EMAC_MODULE);

    if (emac_config.clock_mode != ETH_CLOCK_GPIO0_IN) {
        // 50 MHz = 40MHz * (6 + 4) / (2 * (2 + 2) = 400MHz / 8
        rtc_clk_apll_enable(1, 0, 0, 6, 2);
        REG_SET_FIELD(EMAC_EX_CLKOUT_CONF_REG, EMAC_EX_CLK_OUT_H_DIV_NUM, 0);
        REG_SET_FIELD(EMAC_EX_CLKOUT_CONF_REG, EMAC_EX_CLK_OUT_DIV_NUM, 0);

        if (emac_config.clock_mode == ETH_CLOCK_GPIO16_OUT) {
            PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO16_U, FUNC_GPIO16_EMAC_CLK_OUT);
            ESP_LOGD(TAG, "EMAC 50MHz clock output on GPIO16");
        } else if (emac_config.clock_mode == ETH_CLOCK_GPIO17_OUT) {
            PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO17_U,
                            FUNC_GPIO17_EMAC_CLK_OUT_180);
            ESP_LOGD(TAG, "EMAC 50MHz inverted clock output on GPIO17");
        }
    }

    emac_enable_clk(true);

This is _eth_phy_power_enable(bool enable):
https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/src/ETH.cpp#L45-L50

Code: [Select]

static void _eth_phy_power_enable(bool enable)
{
    pinMode(_eth_phy_power_pin, OUTPUT);
    digitalWrite(_eth_phy_power_pin, enable);
    delay(1);
}

That's a race condition there, will the clock be up and running in time or not? It depends on 1)how long does it take for the clock to start up and 2)how long does the nRST pulse last. To make thing worse there's that delay(1) in _eth_phy_power_enable(). When the clock comes from the esp32, the call to power up the 8710A should be after the call to emac_enable_clk(), me thinks!

The esp-idf part comes precompiled in the Arduino IDE esp32 boards package, so unless we move to platformio or esp-idf, there's not much we can do there, but... we can remove the delay(1) and hope that it helps, because that's not precompiled. It's in:
~/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/WiFi/src/ETH.cpp

Let's try that...

[GeorgeOfTheJungle]

To be completely sure that the 8710 always gets the /reset it needs, put this (to turn it off) before the ETH.begin(..), because the /reset at nRST only happens when going from no-power to power, not if going from powered-on to powered-on:

Code: [Select]

pinMode(ETH_POWER_PIN, INPUT);
digitalWrite(ETH_POWER_PIN, 0);
pinMode(ETH_POWER_PIN, OUTPUT);
delay(99);
ETH.begin(..);
Hey, I'm playing with these changes in place (remove the delay(1) + that above), and it seems to werk !!!

Edit:
I was going to put a scope probe in nRST, but this cheap board has no reset circuitry whatsoever! nRST has its internal pullup, and that's it. Oh, well. This is the sequence of events, blue is the clock, pink is VCC/power input to the LAN8720 board.



Perhaps a /reset is not needed after all?

Edit 2:
It isn't exactly 100BASE-T, more like 17BASE-T, but that's about 2x faster than its WiFi:

[padagra]

The esp-idf part comes precompiled in the Arduino IDE esp32 boards package, so unless we move to platformio or esp-idf, there's not much we can do there, but... we can remove the delay(1) and hope that it helps, because that's not precompiled. It's in:
~/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/WiFi/src/ETH.cpp

Let's try that...

Okay, got that removed.

To be completely sure that the 8710 always gets the /reset it needs, put this (to turn it off) before the ETH.begin(..), because the /reset at nRST only happens when going from no-power to power, not if going from powered-on to powered-on:

Code: [Select]

pinMode(ETH_POWER_PIN, INPUT);
digitalWrite(ETH_POWER_PIN, 0);
pinMode(ETH_POWER_PIN, OUTPUT);
delay(99);
ETH.begin(..);
Hey, I'm playing with these changes in place (remove the delay(1) + that above), and it seems to werk !!!

Got this added as well. ^

Anticlimactically, there are no changes on my manufactured board. I got a few pictures of the results and a video showing how cycling the ethernet plugged/unplugged 6 times will get it to connect, the link light stays off, then you can see it heating up (degrees are in fahrenheit) on the meter.

Video of behavior, it might be hard to see but the green LED is LINK, yellow is ACT - you can see once it gets a connection because the LINK led stops light up and ACT starts flashing:https://www.dropbox.com/s/cijq2uw3j1hg3go/IMG_3256.mov?dl=0

Peak temp with connection the 8710a reached:


Recycled power, lost connection, chip starts to cool back down slowly:



The next move is breadboard now that I have the 8720 dev board in hand it was wishful thinking that making some code revisions may resolve this on my manufactured board but at least it is more data. I have an old NodeMCU ESP32 dev board as well I am going to duplicate your (@GeorgeOfTheJungle) setup on and see if I will get the same results. Tune in next time... 


Edit 1:
I'm getting ripple on PHY_POWER (GPIO12) only when the second oscilloscope probe is probing the 50mhz clock on GPIO17. It is making it difficult to catch the timing on the scope, almost like the probes are interfering with one another through EMI.

Edit 2:

Clean 50mhz clock off GPIO17. Peak to peak I had as high as 5.36v


Ripple shown when both probes are connected for PHY_POWER GPIO12 (Blue)


Ripple on PHY_POWER GPIO12 gone when the clock signal probe removed from the board


Edit 3:
So finally some good news, still not resolved but good news. If you ignore the ripple I assume is EMI from these scope probes on the blue trace, the timing appears to be accurate. Blue is 3.3VLAN. The clock is up before the 8710a gets power.

[GeorgeOfTheJungle]

The things that can draw more power are the drivers of TXP (LAN8710 pin29) and TXN (LAN8710 pin28), pins 1 and 2 of the RJ45. Check these, and check that the 50 Ohms resistors to VDD1A are in fact 50 Ohms. Are you still seeing the TXEN (LAN8710 pin21) pulses flat? Are you sure it's not shorted to anything? If that's still flat it's a signal that something is wrong there. May be the 8710 itself? I would also try an ethernet cable with only 2 pairs, 1,2 and 3,6, just to be sure that the POE thing is out of the equation for the moment.

[padagra]

I would also try an ethernet cable with only 2 pairs, 1,2 and 3,6, just to be sure that the POE thing is out of the equation for the moment.

None of the tests from the beginning of this thread have been with POE. POE works fine but I have been powering up with 3.3v only through the programming header with the bench power supply since it gives me more accurate readings on current draw.

The things that can draw more power are the drivers of TXP (LAN8710 pin29) and TXN (LAN8710 pin28), pins 1 and 2 of the RJ45. Check these, and check that the 50 Ohms resistors to VDD1A are in fact 50 Ohms.

Checked and still not seeing any shorts. I changed them (resistors) out with new as well, they are 51ohm as its the closest value I have on hand at the moment. Additionally I took a new unpopulated PCB and rechecked for continuity where it shouldn't be, no shorts.

May be the 8710 itself?

Swapped this out with a new one, did not have good pad connections probably for lack of solder paste. I put the old one back, got pad connections again and back to the same results. This leads into some theories below, I'm wondering if there's some bad PCB manufacturing issues contributing.

Are you still seeing the TXEN (LAN8710 pin21) pulses flat?

No! Kind of. I am consistently still getting a connection to the web if I plug and unplug the ethernet cable 6 times. 6 times exactly, every single time. Knowing this, the scope shots here are on the 6th connection. The pulses look healthy to me when there is a connection to the web.

First set of packets:


Zoomed in on first pulse of first set of packets:


Second set of packets:



I'm beginning to wonder if the trace connections to the 8710a are causing problems. If you look within the orange boxes, it looks like their pad layout is shifted in the manufacturing from the PCB traces. Its all speculation at this point but possible the heating up is from degraded trace width and current capacity??




I have a bunch of microscope shots of a new, unpopulated board I am working on merging together in photoshop so you can see what I am working with, I will post an edit when it is completed.

[GeorgeOfTheJungle]

How do you solder the GND pad below the 8710A without solder paste? If that's not good the chip may seem to work, and do weird things. I've put a MOSFET to switch on/off the cheap 8720A board with gpio 12, and it always recovers well after an on/off/on, it always works fine.

Edit:
The power consumption I have is 250mA @ 5V => 1.25W, with STA on, AP off, and ETH on, hammering it from the Mac with an ab (apache bench).

[padagra]

No I don't mean I have not used solder paste, I mean when I tried swapping the 8710 out for a new one there wasn't enough residual solder left for a good connection.


Edit 1:

My microscope doesn't zoom out any further, I stitched these images together of the PHY portion of the board. It is a large image.
https://www.dropbox.com/s/s6ug8cbd4bq5rx5/Microscope-Merge.jpg?dl=0

By C15 there is a short with a GND via. I cut that trace out before this thread started so that C15 is lost but there is no short.

Edit 2:
I am drawing 1.332w when the ethernet cable is plugged in and .592w when the ethernet cable is disconnected and board is idle.

[GeorgeOfTheJungle]

Why are there vias in RXER/RXD4/PHYAD0 pin 13, TXEN pin 21, TXD0 and TXD1 (pins 22 and 23). Where do they go?

Edit:
Not in TXEN.



Edit the edit: Ohh yeah, there's another mysterious via in TXEN too:

This leads into some theories below, I'm wondering if there's some bad PCB manufacturing issues contributing.
[...]
I'm beginning to wonder if the trace connections to the 8710a are causing problems. If you look within the orange boxes, it looks like their pad layout is shifted in the manufacturing from the PCB traces. Its all speculation at this point but possible the heating up is from degraded trace width and current capacity??

Looks ok-ish to me :-) Maybe the GND pad is a bit larger than needed?

By C15 there is a short with a GND via. I cut that trace out before this thread started so that C15 is lost but there is no short.

In your schematics that's the "Digital Core Supply Voltage (VDDCR)" 1.2V, I think you should put it back!

Edit #n:

I've put this in my loop() to turn on/off the 8710:

Code: [Select]


String command= "";

void loop () {

...

  while (Serial.available()) {
    int c= Serial.read();
    Serial.write(c);
    if ((c == '\r') || (c == '\n')) {
      if (command.length()) {
        if (command == "flipit") {
          Serial.print("\r\nok\r\n");
          digitalWrite(ETH_POWER_PIN, !digitalRead(ETH_POWER_PIN));
        }
        else Serial.print("\r\nWatt?\r\n");
      }
      command= "";
    }
    else command+= (char) c;
  }
}


[padagra]

Why are there vias in RXER/RXD4/PHYAD0 pin 13, TXEN pin 21, TXD0 and TXD1 (pins 22 and 23). Where do they go?

Edit:
Not in TXEN.

Edit the edit: Ohh yeah, there's another mysterious via in TXEN too:

Pin 21, 22, 23 were mistakes to be honest. I had them in there originally thinking I would have to route on the bottom side, didn't, then forgot to pull them out.

Since starting this project I've learned I need to use a more professional EDA like Eagle but this board was made with EasyEDA. I am able to share the project link for you to view, I probably should have done this sooner. This version is the version I have printed, I have a new project version I have made updates to as I find problems but I have not had that physically manufactured yet I was waiting until resolving this PHY stuff.

https://easyeda.com/editor#id=|2f085ee40f21457f85b840427e71eabe|135d6a3fc5f34003961d1a78c100773c

Looks ok-ish to me :-) Maybe the GND pad is a bit larger than needed?

If you look closely at this picture of the populated board, the pad seems to be shifted. Whereas the stitched together picture of the unpopulated board appears to be correct.

By C15 there is a short with a GND via. I cut that trace out before this thread started so that C15 is lost but there is no short.

In your schematics that's the "Digital Core Supply Voltage (VDDCR)" 1.2V, I think you should put it back!

I will bodge in a 2.2uf or higher cap for VDDCR. I did not have intentions of permanently leaving it out, but couldn't leave that trace connected for this testing. In hindsight, I should have bodged one in sooner... you live and learn. I hope this hasn't been the cause or an additional cause of the mysterious problems.

Edit 1:
Wait.. its not C15 that I lost, its C1 on VDD1A.

[GeorgeOfTheJungle]

Since starting this project I've learned I need to use a more professional EDA like Eagle but this board was made with EasyEDA. I am able to share the project link for you to view, I probably should have done this sooner. This version is the version I have printed, I have a new project version I have made updates to as I find problems but I have not had that physically manufactured yet I was waiting until resolving this PHY stuff.

https://easyeda.com/editor#id=|2f085ee40f21457f85b840427e71eabe|135d6a3fc5f34003961d1a78c100773c[/size]

What a wonderful thing is EasyEDA. I love it.

Wait.. its not C15 that I lost, its C1 on VDD1A.

Fingers crossed!! :-)

[padagra]

Note: VDDCR per the datasheet should be at +1.2v, my oscilloscope shows it at +2.0v.

[GeorgeOfTheJungle]

Note: VDDCR per the datasheet should be at +1.2v, my oscilloscope shows it at +2.0v.

VDDCR comes from VDD1A/VDD2A thru an LDO. The pin LED1 enables/disables the LDO. What does your esp_get_idf_version() say?

[padagra]

Another screen shot of the serial monitor:


I'm at a loss here, I hope you see something on EasyEDA that I'm not because on paper, this schematic, should be working.

[GeorgeOfTheJungle]

Have you put back the capacitor in VDD1A/VDD2A? What happens if you flip it on and off in the serial monitor (with the code I've posted)?

[padagra]

Yes I put a bodge wire in there.



Yes I added your while statement. The first "flipit" turned it off, second "flipit" back on. Same thing though, shows "ETH Connected" recognizing an ethernet cable is plugged in but won't actually get a connection to the web or router.





Edit:

What does your esp_get_idf_version() say?

Code: [Select]

18:35:19.053 -> ETH Connected (SYSTEM_EVENT_ETH_CONNECTED)
18:35:19.053 -> ETH MAC: 24:0A:C4:23:FC:27, IPv4: 192.168.1.86, FULL_DUPLEX, 10Mbps
18:35:19.053 -> v3.2-18-g977854975