So, I have 2 of my 7 assembled boards that weren’t working as expected. I was able to quickly narrow it down to the connection between the two PHY’s (uh-oh). Immediately I was suspicious of my home-brew coupling network that replaced the magnetics we normally see.

After a lot of sniffing around the circuit I wasn’t able to see anything out of the ordinary. FLPs (Fast Link Pulses) were being sent and received by both PHYs, but no link was ever established. I ended up comparing to some of my known good PCBA’s and noticed something interesting about the FLP of my problematic DUT. 

Here’s what the FLP’s look like that are being received by the IC+ PHY on my problematic unit.

And here’s what those same signals look like on a working device.

Very odd. I thought this difference could be caused by a lack of Vref on IC+ (since the rail seems to sit around 3V3 when I’d expect it to be closer to 1V8), but after looking closer at the supporting passives around the IC+ PHY everything seemed in working order. 

I also took some wider captures of the entire startup hoping to gain some insight, but there was nothing else unique I could find between my two DUT’s.

This issue led to a LARGE LARGE LARGE rabbit hole of trying to read the internal registers of the Microchip PHY (the one sending the above pulses). There are some very handy registers that would have helped me debug this issue (see below).

Sadly, I burned half a day trying to configure a system to read/write the registers of the device using blueTag and OpenOCD. BlueTag was able to recognize the device, but past that I was never able to make any significant progress in this endeavor. 

To unstuck myself, I decided to disable auto-negotiations since that’s where everything seemed to be hanging (you can do this just in device manager). Doing this resolved the communication issue. If this is the fix I choose to implement it means the end user would have to muddle around in device manager before using their HUB (not ideal). 

So, I have two options to investigate further. (1) Redesign the coupling network to resolve the auto-negotiation hiccups, or (2) add an EEPROM to the PHY that will store the default setting as 100base-t. Both of these options are supported by the copper on rev 1.