W7500P PHY Unable to Link

Question

Hello, I am working on a board based around the Wiznet W7500P, I'm using the standard peripheral library from the Wiznet GitHub. With a design functionally identical to the reference schematic. Recently one of my units fails to establish a link with a connected ethernet cable, the same firmware and hardware succeed on an identical unit. This behavior persists between soft resets of the PHY, toggling RSTn on the W7500P and full power cycling of the board, leaving the board in an unusable state. I was able to dump the PHY registers on my working unit ===== IP101G PHY register dump (PHY addr 1) ===== -- Page-independent registers (Reg) -- Reg 0 = 3100 Control Register Reg 1 = 786D Status Register Reg 2 = 0243 PHY Identifier 1 Register Reg 3 = 0C54 PHY Identifier 2 Register Reg 4 = 01E1 Auto-Negotiation Advertisement Register Reg 5 = 45E1 Auto-Negotiation Link Partner Ability Register Reg 6 = 0005 Auto-Negotiation Expansion Register Reg 7 = 2801 Auto-Negotiation Next Page Transmit Register Reg 8 = 0000 Auto-Negotiation Link Partner Next Page Register Reg 13 = 4007 MMD Access Control Register Reg 14 = 0000 MMD Access Address Data Register Reg 20 = 0010 Page Control Register -- Paged registers (page.reg) -- 1.17 = 0000 PHY Specific Control Register 1.18 = 0000 RX CRC Error Counter Register 1.22 = 2020 Linear Regulator Output Control Register 1.23 = 8000 UTP PHY Specific Control Register 2.18 = 0000 RX Packet Counter Register 3.16 = 0000 LED Control Register 4.16 = 5F40 WOL+ Control Register 4.22 = 4000 Digital IO Pin Driving Control Register 5.16 = 0000 PHY WOL+ MAC Address Register 8.17 = 7000 RX Counter Control Register 11.18 = 0000 UTP PHY Interrupt Control/Status Register 16.16 = 0002 PHY Specific Control Register 16.17 = 0F00 PHY Interrupt Ctrl/Status Register 16.18 = 6D0A PHY Status Monitoring Register 16.26 = 1249 Digital IO Pin Driving Control Register 16.27 = 0012 Digital IO Pin Driving Control Register 16.29 = 0182 Digital I/O Specific Control Register 16.30 = 0106 PHY MDI/MDIX Control and Specific Status Register 17.17 = 0000 PHY WOL+ Status Register 18.17 = 0000 RX Counter Interrupt Control/Status Register -- MMD registers (devad.addr) -- 3.0 = 0000 PCS Control 1 Register 3.1 = 0000 PCS Status 1 Register 3.20 = 0002 EEE Capability Register 3.22 = 0000 EEE Wake Error Count Register 7.60 = 0002 EEE Advertisement Register 7.61 = 0000 EEE Link Partner Ability Register ===== end of dump ===== As well as on a malfunctioning unit ===== IP101G PHY register dump (PHY addr 3) ===== -- Page-independent registers (Reg) -- Reg 0 = 2100 Control Register Reg 1 = 7849 Status Register Reg 2 = 0243 PHY Identifier 1 Register Reg 3 = 0C54 PHY Identifier 2 Register Reg 4 = 01E1 Auto-Negotiation Advertisement Register Reg 5 = 0000 Auto-Negotiation Link Partner Ability Register Reg 6 = 0004 Auto-Negotiation Expansion Register Reg 7 = 2001 Auto-Negotiation Next Page Transmit Register Reg 8 = 0000 Auto-Negotiation Link Partner Next Page Register Reg 13 = 4007 MMD…

kelanucr · Answer

It does seem like Auto-MDIX is still functioning as I can see the TX/RX pair occasionally flip on my scope. The fault seems to occur at auto-negotiation, the default state of AN_ARBIT_STATE is 0x8 (AUTO NEGOTIATION ENABLE) and is moving to 0x0 (TRANSMIT DISABLE) then timing out after 5s which means that it is not advancing to ABILITY DETECT. and the break_link_timer is not expiring. break_link_timer not expiring would either point to a clock issue where the timer itself is just not advancing or an external event resetting the clock, or some unrecoverable fault in the AN state machine. The clock itself is outputting at 25MHz and I assume that the Auto-MDIX timing is managed by the clock so the clock seems to be fine. I am unsure what type of external reset would be causing break_link_timer to reset. To rule out a faulty AN state machine on the IP101G I set Auto-Negotiation Enable to 0, Speed Selection to 1, and Duplex Mode to 1. The description of Auto-Negotiation Enable says these are the only bits that need to be set for forced mode but I still did not see anything on my scope. I then tried setting FORCE_LINK_100 to 1 and still did not see anything (I also tried disabling low power mode by setting LDPS_ENABLE to 0 and NWAY_PSAVE_DIS to 1). As a tangent, suddenly the soft reset to bring the board back to TP mode was not working, so I revisited PHY_Init() and found a working combination to bring up in TP mode. GPIO_PinPadConfig(GPIOB, GPIO_PinSource12, GPIO_PuPd_DOWN|GPIO_InputBufferEnable|GPIO_CMOS); GPIOB->OUTENSET = GPIO_Pin_12; GPIO_ResetBits(GPIOB, GPIO_Pin_12); // COL (collision detect in normal mode)/RMII (MAC interface mode on reset high for RMII 0 for MII) // RMII is Reduced MII (uses 7 lanes instead of 16) // This shouldn't work? It doesn't seem to matter GPIO_PinAFConfig(GPIOB, GPIO_PinSource5, PAD_AF1); GPIO_PinPadConfig(GPIOB, GPIO_PinSource5, GPIO_PuPd_UP|GPIO_InputBufferEnable|GPIO_CMOS); // DUP (duplex mode) GPIO_PinAFConfig(GPIOB, GPIO_PinSource6…

kelanucr · Answer

I have noticed I can replicate this failure mode on a working unit by modifying my link poll loop, which just calls PHY_GetLinkStatus when no link is detected, to instead first call PHY_Init(). Then after reconnecting a link partner the link fails to come up. This leads me to believe that the startup state of the IP101G is, in addition to causing it to sometimes boot in FX mode, causing the link to fail to come up.

kelanucr · Answer

Hi, I have tried adjusting the strap logic, here is what I have at the moment // initialize PHY strap pins phy_strap.GPIO_Pin = GPIO_Pin_12 | GPIO_Pin_5 | GPIO_Pin_6; phy_strap.GPIO_Direction = GPIO_Direction_OUT; phy_strap.GPIO_Pad = GPIO_InputBufferEnable | GPIO_CMOS | GPIO_PuPd_DOWN; phy_strap.GPIO_AF = PAD_AF1; GPIO_Init(GPIOB, &phy_strap); // initialize reset pin phy_reset.GPIO_Pin = GPIO_Pin_6; phy_reset.GPIO_Direction = GPIO_Direction_OUT; phy_reset.GPIO_Pad = GPIO_PuPd_UP; phy_reset.GPIO_AF = PAD_AF1; GPIO_Init(GPIOD, &phy_reset); // configure strap GPIO_ResetBits(GPIOB, GPIO_Pin_12); // FX/TP mode GPIO_SetBits(GPIOB, GPIO_Pin_5); // RMII mode (I also tried MII mode) GPIO_SetBits(GPIOB, GPIO_Pin_6); // duplex // reset sequence GPIO_ResetBits(GPIOD, GPIO_Pin_6); ms_delay(15); GPIO_SetBits(GPIOD, GPIO_Pin_6); ms_delay(15); You mentioned RMII, but the W7500P ref manual says it uses MII; so I tried setting both. I have tried setting the restart auto negotiation bit.

kelanucr · Answer

Warming the board by about 10F from the ambient room temperature of about 70F causes all pins on the package to become shorted. I'm going to conclude that this particular unit was damaged from improper ESD protection on the board. I noticed that on the development board schematic an additional ESD protector was installed, which my board does not have. Additionally, I believe the intermittent link state of the working boards is caused by EMI and improper decoupling after looking at the other posts on this form ie, link issues when near a servo or relay.

kelanucr · Answer

I'm not able to share the full schematic files, but it is functionally identical to the reference schematic from the WizNet Github. The only difference is that the GPIO pins are fanned out to headers but these headers are currently unpopulated. I've since swapped the uC and haven't had this problem yet again. I did notice though that on another board the PHY link would fail intermittently when attaching external devices to the headers. When attaching an external device with decoupling capacitors the inrush current caused oscillations on the primary and analog 3v3 voltage rail causing swings above 4v and below 3v. That is my new theory on what may have killed the PHY.