PHY Link Detection Fails

Here is the hardware side:
Schematic
Note: PMODE0, PMODE1 and PMODE2 are all tied to 3.3V. J4 is a pigtail RJ45 cable.

On the firmware side, I have
static wiz_PhyConf phyConf =
{
PHY_CONFBY_SW,
PHY_MODE_AUTONEGO,
PHY_SPEED_10,
PHY_DUPLEX_HALF
};

ctlwizchip(CW_SET_PHYCONF, (void*) &phyConf);

To poll the PHY Link, I have

int8_t tmp;

tmp = wizphy_getphylink();
if (tmp == PHY_LINK_ON)
{
	
 }

This has been working fine with my router in my office. However, when test units are plugged into other part of company network, they don’t detect the PHY link. I searched this forum. Threads from a few years back seem to suggest the problem was related to auto negotiation on some of the routers. I am not sure what I should do because I don’t know enough about auto negotiation.

Some clever networking devices, when sense that there’s something in their network port jack, start process of 'blocking, listening, or learning states", or even line training to identify what type of cable is connected. This process may take up to a minute, thus device plugged into router will not be able to access the network for quite a long time after it was plugged OR after it performed link down/up operation (note: W5500 performs link down/up when hardware or software reset).

Check this article from Cisco. Cisco devices are having PortFast feature:

If you connect a workstation or a server with a single NIC card or an IP phone to a switch port, the connection cannot create a physical loop. These connections are considered leaf nodes. There is no reason to make the workstation wait 30 seconds while the switch checks for loops if the workstation cannot cause a loop. Cisco added the PortFast or fast-start feature. With this feature, the STP for this port assumes that the port is not part of a loop and immediately moves to the forwarding state and does not go through the blocking, listening, or learning states. This command does not turn STP off. This command makes STP skip a few initial steps (unnecessary steps, in this circumstance) on the selected port.

which allows configuring port not performing start-up operations when connected, and go directly into forwarding operation.

If your router does not have such option, the only way I see is connecting W5500 to a simple hub device, and then connect that hub device to the router of the network. In this situation if W5500 will perform up/down of its PHY, another hub’s port will still stay up for the router device.

Found the problem. The PHY link up actually works fine. What failed was the DHCP part, when the device was plugged into the company’s intranet. The DHCP process can take much longer than plugging to a local router. This causes the DHCP code to time out. I am using the DHCP code from the WIZnet ioLibrary.

1 Like