Ethernet PHY best practices for low cost design

[AloyseTech]

Hi,

I'm currently designing a low-cost device which needs Ethernet connectivity. I selected the LAN8720A PHY for its availability and cost.

I understand the clocking of the PHY and MAC is a bit tricky and that there are a few possibilities.
The current documentation states 3 modes:
A. The PHY is clocked with a low cost 25MHz crystal and derive a 50MHz clock to the ESP32 GPIO0.
B. Both the PHY and the MAC are clocked with an expensive 50MHz oscillator.
C. The MAC outputs the 50MHz clocks using either GPIO0, GPIO16 or GPIO17.

I understand the solution C is the lowest cost one(only 1 GPIO is used, no crystal, no oscillator, no special circuit to disable clocking during GPIO0 strap sampling). I wanted to confirm that this solution is considered stable and can be implemented in an actual product. Using GPIO0 to output the clocks is marked as experimental. Is it also the case for GPIO16 and 17? Is there a functional difference between using GPIO16/17 and GPIO0 ? I understand the clock is generated using an internal PLL system. Does it restrict other internal usage in this case?

Solution A. would be an alternative because it is not much more expensive (still only one GPIO used and the 25MHz crystal costs ~$0.05). The documentation warns about the fact that when held in reset, some PHY might still output the 50MHz clock and thus interfere in the boot process (GPIO0 strap sampling). Is it the case for the LAN8720A? Or this solution can be used safely?

Solution B is the most expensive (a 50MHz oscillator costs around $0.30 and I need an additional GPIO to control the enable line of the oscillator). What are the advantages of using this solution? I suspect it might be more robust but I'm not really sure.

Thanks in advance for any help and advice on using Ethernet with the ESP32.

[PeterR]

You might gain inspiration by looking at the ESP-EVB
https://raw.githubusercontent.com/OLIME ... _Rev_F.pdf
which uses an 8710

Many have used this board.
There used to be a few posts about difficulties with the LAN PHY but I have not seen any for a while.
You need to be very careful with your reprogramming circuit though.

GPIO0 is the standard approach. I am sure that you will loose some options when using another pin. I have not tried, stick with reference is my motto!
The GPIO MUX documentation will tell you what you might loose. It very much depends what you need - as you might imagine not all pins behave the same and so you have to play GPIO sudoku with your feature list.

[AloyseTech]

Thanks Peter for your reply. I know the programming/reset circuit must be designed with care if the clocking is done using GPIO0 as an input. My question is more oriented on the other solution though, which fit my constrains better (low cost, low components count).
Of course the goal is to have something that works reliably. if this is possible using IO16/17 as clock output I would prefer this solution. But since I have no idea how much of a hack this is, I wanted to have some insight from the developers.

[PeterR]

It is interesting that the EVB uses GPIO0 for all the problems this can cause.
I use GPIO0 so I cannot tell you!

[deimos]

Hi,

I designed a board using the LAN8720A using the clockout of the ESP on GPIO17.
The hardware works perfectly, but I had a software issue on IDF 4.0.1 (see https://github.com/espressif/esp-idf/issues/5425).

Alex

[ESP_Sprite]

It is interesting that the EVB uses GPIO0 for all the problems this can cause.
I use GPIO0 so I cannot tell you!

A possible reason is that GPIO17 is used by PSRAM on modules/boards that have it.

[AloyseTech]

@ESP_Sprite: It appears the ESP32 EVB from Olimex does not have on-board PSRAM (ESP32-WROOM-32). Would you consider the clocking of the PHY through IO16/17 or IO0 a stable feature in IDF >v4.x.x ? EDIT: Do you have more information also on using a 25MHz crystal with the LAN8720 and feeding the REFCLKO to GPIO0 (and the status of REFCLKO when the LAN is held in reset) ?

@deimos: thanks for sharing your issue. I did not find any mention in the datasheet of a register update delay/timing though. Do you think it could be related to a clocking issue (i.e a late startup of the clock or clock stability error) ?

[mikemoy]

To get around the issue with option A, that interferes with flashing when using GPIO0, I used the EN pin of the ocilator to disable its clock output. See post here.
viewtopic.php?f=17&t=5479&start=30#p55405

I have not tried Option C, though if i ever tried to re-design the board that is the route I would try. I would suggest you simply buy a LAN8720A breakout board, and give it a try for yourself so you can test all your options.

[deimos]

@deimos: thanks for sharing your issue. I did not find any mention in the datasheet of a register update delay/timing though. Do you think it could be related to a clocking issue (i.e a late startup of the clock or clock stability error) ?

It is not an issue on updating register in generel, it is just an issue on this powerdown register. I think, powering the PHY using this register will do the same stuff inside the LAN8720 as a hardware reset using the RST Pin, which has some notes about the timing in the datasheet. I don't think, that it is a clock related issue, as there is just the check for the register value and the value will change, but it takes some time for it.

[deimos]

It is interesting that the EVB uses GPIO0 for all the problems this can cause.
I use GPIO0 so I cannot tell you!

As I understood, Olimex did the design at a time where were no support for the clock output on GPIO17 in esp-idf. On the ESP32-PoE-ISO they changed the design and use the GPIO17 instead of GPIO0.