Close

The PHY reset saga

A project log for wESP32: Wired ESP32 with Ethernet and PoE

A low cost ESP32 core board with Ethernet and PoE for convenient "single cable" deployments

patrick-van-oosterwijckPatrick Van Oosterwijck 03/11/2019 at 16:094 Comments

Finally, a long overdue update! The silence doesn’t mean we’ve been taking it easy, on the contrary: we’ve been hard at work to make the wESP32 even better!

A yield problem

After the initial build of 245 units, we were able to ship 205 units that were good right away. There were various issues with the remaining 40, but the vast majority of them had the same problem: the Ethernet PHY would not get initialized properly.

The LAN8720A Ethernet PHY is kind of a difficult part. It has several pins that have double use: during reset their logic level indicates various configuration settings, while after reset they are used in the RMII interface to communicate with the ESP32. An extra difficulty is that the chip expects the 50 MHz clock to be present during reset, so the chip can clock in these configuration settings.

Unfortunately, the ESP32 by default uses the IO0 pin for the Ethernet MAC clock. (More options have become available for dealing with the Ethernet MAC and PHY clocks, but because IO0 was the first option available in the SDK, it enjoys the broadest firmware support so that’s why I keep using it. Plus to keep as many other ESP32 pins as possible available to the user!) The ESP32 IO0 pin is kind of a difficult pin as well, since it is used on reset to determine whether the ESP32 should go into programming mode or run the current firmware. So we have a perfect storm of an IO0 pin that needs to be high at boot to run normally, but low at boot to go into programming mode, and needs to have the 50 MHz clock on it after boot to allow Ethernet communication, and that before the PHY comes out of reset.

When I designed the wESP32, I just looked at how Olimex dealt with the IO0, ESP32 reset and PHY reset on their ESP32-GATEWAY and copied that for the wESP32, figuring they must already have found a good solution since this was a product in production. On my first hand-built prototypes, it all worked well, so I went ahead with it in production. Then I found that more than 10% of the boards had an issue. Interestingly, in their latest revisions, Olimex has changed their product to use IO17 as PHY clock output to bypass the whole problem! This might be a smart thing to do, but I am loath to make backwards incompatible changes and take a precious GPIO pin away from the user. So I started looking at other ways to deal with this.

Looking for a solution

I needed a solution that would act as a reset manager for the 50 MHz oscillator and Ethernet PHY and would be triggered by the EN signal to the ESP32. When EN is low on power-up and when triggered by a programmer, the 50 MHz oscillator needs to be off, so the programmer can drive the IO0 pin low to enter programming mode, or the IO0 can stay pulled high and the system boots. The PHY needs to be kept in reset as well, because its reset can only be released after the 50 MHz clock has started up. After the ESP32 has had the opportunity to determine the boot state, the 50 MHz clock needs to be turned on, and only after the clock signal is present can the PHY reset be released.

I had assumed there would be plenty of low cost, SOT packaged voltage detectors and reset managers that could replace my existing solution in the space I had available, but to my great surprise, nothing I could find in the market really seemed to fit the bill. There are plenty of supervisors that monitor multiple voltages and generate a reset, but I couldn’t find any low cost options that monitor one input and generate two reset signals with separate delays.

So I started thinking outside the box: did I really need to add a little microcontroller to do this? There are several microcontrollers that are cheaper than higher end supervisor chips, and it would give me full flexibility to generate the reset signals exactly how I wanted them. On the other hand, I didn’t really want to deal with programming this micro on every board. I would need to add programming pads and a manufacturing step to perform programming. Ideally I would be able to order factory programmed chips and avoid all that. To me, this would just be a simple fixed function chip that does what I need it to do.

The PMS150C solution

In looking for really low cost micros, I came across some EEVBlog videos about a three cent microcontroller. Extremely low cost OTP chips, with factory programming available: this seemed perfect for this! So I ordered the emulator, programmer and some Padauk PMS150C chips in SOT-23-6 package and once I received them I got to work.

I agree with Dave Jones that the tools for these chips are really quite good! In a weird, quirky sort of way, with a C-like language that has additional shortcuts and directives, and lots of Chinglish instructions. But with all the GUI settings screens and examples provided, I had no issue getting my simple program done with a minimal amount of fuss. I didn’t even have the emulator yet at the time so I just burned a chip, hacked it on to one of the errant wESP32 boards and gave it a try.

And it works beautifully, pretty much from the first try! The only thing I had to adjust was adding a pull-down resistor to the enable pin of the 50 MHz oscillator, to make sure it stays off during the brief period after power-up when the PMS150C is still in reset and not driving the oscillator’s enable pin yet. Which is not a big deal for the PCB redesign, because I have an unused 10K resistor available in resistor array R6 right next to the chip!

Below is a trace of the EN signal to the ESP32 releasing in yellow, and the enable pin of the 50 MHz oscillator being driven high from the PMS150C after a delay of about 200 ms:

And here is the reset to the PHY chip in blue, being release about 100 ms after the 50 MHz clock in yellow is started:

Of course, I had to gain a little more confidence before I went ahead with this, so I hacked eight more boards this way to verify whether everything worked:

And they’re all working great!

So then I needed to actually be able to get factory programmed parts. This would only be a practical solution if I could get reels of these chip factory programmed and ready to use by the CM, just like any other fixed-function part. That’s where I hit a snag. According to Dave Jones, LCSC had told him they could provide this service. However, when I got in touch with them, they said they don’t do it. I tried to contact several of Padauk’s listed authorized resellers, but never got any response. In desperation I contacted Padauk directly and they responded and got me a contact at Sino-Mos, who I’m working with now to get these custom programmed parts manufactured. The chips are a little more than three cents each when factory programmed, but nothing to complain about. I figure that with shipping included, they will still be less than eight cents each. I do need to buy 9,000 of them at once though, so I hope the wESP32 will keep selling well after this. :)

Once everything is straightened out and I have an order confirmation, I will go ahead and order 1000 revised PCBs and hopefully get the next batch of wESP32s built soon. In the mean time, thank you for your patience as the shipping date has been slipping. But I think we’re out of the woods now!

Discussions

roma wrote 08/13/2020 at 16:49 point

I was wondering why wouldn't a little bit of startup delay (esp32 side) solve the PHY reset issue? I mean, to keep LAN8720A without RX/TX until reset procedure is done? Thanks in advance

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/05/2021 at 19:14 point

I'm not entirely sure what you mean.  This was the best solution I could find, but definitely not the only solution, especially if you don't mind sacrificing ESP32 IOs.
That said, the LAN8720 is just trouble and I'm replacing it with the RTL8201 in the next revision.

  Are you sure? yes | no

dmitrij9992905 wrote 04/16/2020 at 22:09 point

How about switching off PHY module power by default physically (with MOSFET or apart LDO with EN input) and switching on after ESP32 normal boot?

  Are you sure? yes | no

Patrick Van Oosterwijck wrote 08/05/2021 at 19:12 point

I was trying to find a solution that would preserve as many IOs as possible for the user.

  Are you sure? yes | no