Electronics > Microcontrollers

LAN8720 PHY IC requires delay after reset?

<< < (3/3)

I added schematic of PHY IC on board.

With the boot pins = 111 you have auto-negotiation enabled.  Maybe this just takes a few seconds in your particular setup.  (Patch cable directly to your laptop?)

I think I would watch the basic status register, or similar, and timestamp and decode/log it to the console whenever it changes.  This would give a clue as to what's going on, watching what it's doing, and at which stage it's working again.  My wild guess is when you hit reset it also up ends up seeing a spurious link fault - or something.  (Or the other end does.)  It's probably not the best to reset the PHY while the cable is plugged in anyway.

Ethernet cable was directly connected to my PC. I found a work around by replacing

--- Code: ---while(!(ETH_ReadPHYRegister(ETH_EXTPHY_BSR) & 0x4));

--- End code ---


--- Code: ---uint16_t tempReg;
DummyDelay(250); //250ms delay
tempReg = ETH_ReadPHYRegister(ETH_EXTPHY_BSR);
while(!(tempReg  & 0x4));

--- End code ---

Which basically checks the link status every 250ms instead continuously. This resulted in connection time of approximately 2 seconds instead of 4-5. I still don't know what I am doing wrong and inner workings of the IC.

I tried logging Basic status register, but everything seems fine before and after the link status check and autonegotiation complete check.


--- Quote from: syntax333 on June 23, 2022, 04:46:05 am ---I am pressing reset button on nucleo board to reset both MCU and ETH PHY.  Reset line connected both MCU and ETH PHY in nucleo board.


Also I realised that If I flash the code it runs fine. However, If I issue a reset or plug out/in the power after flashing code it won't run. That is the main problem I think.
--- End quote ---

That makes sense if your toolchain and programming interface are configured to soft reset the MCU after programming, since it won't cause a hardware reset to the PHY.  So the PHY will still be up and running from the last reset unless/until you issue a soft reset.

Speaking which, it's hard to offer advice when you aren't clear and consistent in your description of the problem.  You started off asking about hard reset, but then the code you posted shows the MCU issuing a soft reset, which confuses what's going on and makes it harder to help you.  If you're making changes to the code as you troubleshoot that's fine, but please be clear about which changes to the code or your programming/reset process have what effects on the system behavior. 

--- Quote ---The screen shot I sent shows MDC so after reset I am constantly checking Link status. I didn't checked other RMII lines. I am waiting for DMA to release the descriptor ((" while(TxDescriptorTable.Status & ETH_DMATXDESC_OWN); //wait until DMA release Descriptor" )).
--- End quote ---

Sure, your code is waiting for the descriptor to be released, but is that actually happening?  Without information like this it's harder to tell where the problem is. 

All that aside, if the link comes up faster when you reduce the polling rate, then my guess is that servicing an SMI transaction is keeping the PHY's internal logic from getting the link worked out or performing whatever other reset housekeeping it needs to do.  I don't know how PHYs are designed internally but given how much work they do I could believe there's something like a little general purpose processor core in there that handles a lot of the configuration and housekeeping necessary to manage the link hardware, and it probably wasn't designed to service SMI continuously at the rate that something like an STM32F4 can poll it during otherwise normal operation.


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version