ESP32 Forum

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.

I think you are referring to option B where an external 50MHz oscillator is used (they usually have an enable pin). For option A there is no enable on passive crystals, so one must ensure the LAN8720 REFCLKO pin is tri-stated when the held in reset mode. The esp-idf documentation mention the possibility that some PHY still output the 50MHz derived from the crystal even when 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) ?

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.

This is strange. I would understand if it was the Software Reset bit that was written but in this case it's the Power Down bit which should not trigger a reset (and thus require some delay). The delays mentioned in the datasheet are all in the sub-millisecond range other than the power supply to RST of >25ms and the Soft Reset maximum duration of 500ms.

This is strange. I would understand if it was the Software Reset bit that was written but in this case it's the Power Down bit which should not trigger a reset (and thus require some delay). The delays mentioned in the datasheet are all in the sub-millisecond range other than the power supply to RST of >25ms and the Soft Reset maximum duration of 500ms.

Have a look at the linked Github issue. On the software reset register there is already some code to wait for the register change. And the mentioned issue is not when setting the powerdown register (which is "instant"), instead when clearing it (for powerup).

Great contributions, learning a lot.
IMHO GPIO0 is not a great solution, GPIO0 has 'bitten my butt' more than once. GPIO17 is not suitable for WROVER & PSRAM users (& who would not want 4MB of RAM!) because ROM (?) locked GPIO17 as PSRAM CS.
How do we stand on GPIO16 citations?

GPIO17 is not suitable for WROVER & PSRAM users (& who would not want 4MB of RAM!) because ROM (?) locked GPIO17 as PSRAM CS.
How do we stand on GPIO16 citations?

On the WROVER IO17 is SRAM clock and IO16 is SRAM chip select. So both are out of the equation...

IO16 and IO17 are respectively EMAC_CLK_OUT and EMAC_CLK_OUT_180 (i.e. 180° phase shift or inverted clock) generated by the EMAC peripheral, while IO0 clock output is generated by the APLL.
Some early designs using GPIO0 as the clock output used external inverting buffer before the PHY. I don't know if this is to solve a timing issue internal to the ESP32 (APLL sync with the EMAC or MUX/GPIO propagation delay for example) or if this is to solve a potential "external" timing issue on the PCB, or even PHY-dependent. So I suspect one can't be sure which one of the two EMAC_CLK_OUT GPIO will work in advance.

Hi deimos,

small digression, you said LAN8720A is available. Man, i have been looking for it for a while now, looks like i can't find any reliable place to get 100 of those.

Any sggestion? Thnx

@AloyseTech I am in a similar postion as you and need to use ethernet in one of my designs. I was wondering what you finally did and if you would be willing to share that with us.

Thank you

GPIO17 is not suitable for WROVER & PSRAM users (& who would not want 4MB of RAM!) because ROM (?) locked GPIO17 as PSRAM CS.
How do we stand on GPIO16 citations?

On the WROVER IO17 is SRAM clock and IO16 is SRAM chip select. So both are out of the equation...

IO16 and IO17 are respectively EMAC_CLK_OUT and EMAC_CLK_OUT_180 (i.e. 180° phase shift or inverted clock) generated by the EMAC peripheral, while IO0 clock output is generated by the APLL.
Some early designs using GPIO0 as the clock output used external inverting buffer before the PHY. I don't know if this is to solve a timing issue internal to the ESP32 (APLL sync with the EMAC or MUX/GPIO propagation delay for example) or if this is to solve a potential "external" timing issue on the PCB, or even PHY-dependent. So I suspect one can't be sure which one of the two EMAC_CLK_OUT GPIO will work in advance.