My W5500 is stuck in 10MBPS 1/2 Duplex mode. When it auto negotiates with my switch, it won’t choose 100MBPS / Full Duplex. Further, Even if I set the phy to 100mbit it just falls back to 10mbps immediately.
It seems PHY_MODE_AUTONEGOoverrides all other settings and causes chip to auto-negotiate, and it can only auto-negotiate at 10M/H. Why? No idea… probably other device is set to auto-negotiate too, and they start with 10M/H and find connection and even do not try higher speeds and full duplex. Check and play with other device’s settings.
I’ve verified the issues directly on a switch that I know works properly. Auto negotiation does not start at the slowest speed, it will agree on the fastest speed (bandwidth actually) that both sides support and configure for that.
Basically, when set to auto negotiate or HW controlled it will connect at 10M Half duplex, whereas if I force it to 100M Full, it works there as well.
UPDATE: OK, I think it is negotiating correctly to 100M however this doesn’t seem to be reflected when calling the function “void wizphy_getphyconf(wiz_PhyConf* phyconf)” and I’m not sure that the function is even correct looking at how it works.
If I call the following function I appear to get the results I expect so whilst not being a huge issue, I’d still like to get to the bottom of why the above function works in the way it does.
Yes, I am getting the correct return from getPHYCFGR(), the problem seems to be with that I was using function void wizphy_getphyconf(wiz_PhyConf* phyconf) to read the results. Looking at this function, and based on getPHYCFGR returning a value of 255 for 100M Full, Auto Negotiation the function is loading the following into the phyconf structure.
255 & (7<<3) = 56 → Goes to default, this is incorrect and will never match the first two cases.
switch(tmp & PHYCFGR_OPMDC_ALLA)
{
case PHYCFGR_OPMDC_100FA:
case PHYCFGR_OPMDC_100F:
case PHYCFGR_OPMDC_100H:
{
phyconf->speed = PHY_SPEED_100;
break;
}
default:
{
phyconf->speed = PHY_SPEED_10;
break;
}
}
Again, 255 & (7<<3) = 56 → Goes to default, this is incorrect and will never match the first three cases.
This is where I’m getting the incorrect result from. As you suggested, if I just look at the bit result from getPHYCFGR() then I guess that will give me the correct result. Just think that the above function I highlighted needs to be looked at.