Ethernet PHY best practices for low cost design

AloyseTech
Posts: 22
Joined: Mon Jul 22, 2019 2:29 pm

Re: Ethernet PHY best practices for low cost design

Postby AloyseTech » Fri Jul 10, 2020 1:37 pm

mikemoy wrote:
Fri Jul 10, 2020 11:16 am
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 wrote:
AloyseTech wrote:
Fri Jul 10, 2020 8:29 am
@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.

deimos
Posts: 8
Joined: Thu Jul 09, 2020 5:36 pm

Re: Ethernet PHY best practices for low cost design

Postby deimos » Fri Jul 10, 2020 10:42 pm

AloyseTech wrote:
Fri Jul 10, 2020 1:37 pm
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).

PeterR
Posts: 621
Joined: Mon Jun 04, 2018 2:47 pm

Re: Ethernet PHY best practices for low cost design

Postby PeterR » Fri Jul 10, 2020 11:12 pm

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?
& I also believe that IDF CAN should be fixed.

AloyseTech
Posts: 22
Joined: Mon Jul 22, 2019 2:29 pm

Re: Ethernet PHY best practices for low cost design

Postby AloyseTech » Thu Jul 16, 2020 9:37 am

PeterR wrote:
Fri Jul 10, 2020 11:12 pm
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.

nardev
Posts: 1
Joined: Wed May 31, 2017 10:02 pm

Re: Ethernet PHY best practices for low cost design

Postby nardev » Tue Jun 29, 2021 4:45 am

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

kapurar
Posts: 1
Joined: Thu Nov 03, 2016 2:41 pm

Re: Ethernet PHY best practices for low cost design

Postby kapurar » Sat Apr 15, 2023 12:49 pm

@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


AloyseTech wrote:
Thu Jul 16, 2020 9:37 am
PeterR wrote:
Fri Jul 10, 2020 11:12 pm
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.


Who is online

Users browsing this forum: No registered users and 73 guests