Unexpected PHY output (KSZ8091RND) - Page 1
Forum section: electronics / general

author: PDP-1
author_rank: Contributor
timestamp: January 03, 2024, 08:17:11 pm
content: Hi all,I have a KSZ8091RND Ethernet PHY chip that I'm driving from a STM32F427VGT6 microprocessor. The RMII control of the PHY seems to be fine, I can read and write the PHY registers as expected. When I plug an Ethernet cable in the PHY detects the presence of a link partner correctly and reports that it has autonegotiated a 100Mb, full duplex connection.However, when I try to send a broadcast packet from my PHY the activity light on the receiving switch flickers as if some signal is being picked up but no data is passed to any of the other ports. When I used a different cable and direct connected my circuit to the Ethernet port of a PC running Wireshark I still do not see any broadcast packets getting through.I commanded the PHY to not auto-negotiate but to always run in 10Mbit/s mode to slow the signals down. I put two scope probes on the Tx+ and Tx- pins of my PHY (red and black traces), then take the difference between them (green) and then ran the STM32/PHY off of one channel of a function generator and plot a 10MHz signal (blue) off of the other channel so that the two signals should remain phase locked. Then, if I understand things correctly the bit values of the PHY Tx output can be read by looking at whether the green differential signal is positive (1) or negative (0) when the blue clock line has a downward transition.What I expected at the start of a packet was a preamble of seven bytes of 0xAA, followed by a start of frame delimiter of 0xAB. What I got was one byte of 0xAA followed by something starting in 0xF. Is this giving me an invalid preamble that causes all of my packets to get dropped on the other end? I thought the PHY would autogenerate that sequence of bits for me. Is this signal truly wrong or do I just not understand the packet header format correctly?

author: bson
author_rank: Unknown
timestamp: January 09, 2024, 09:14:29 pm
content: Either end could detect a loop and jam the signal to abort the frame. Just a thought.

author: selcuk
author_rank: Frequent Contributor
timestamp: January 09, 2024, 09:52:20 pm
content: MCU talks via MDIO and MDC pins for registers. Ethernet communication is transferred over Tx and Rx lines. Since link can go up, I would check 50MHz clock. Is there a buffer delaying the clock? Maybe there is a phase difference between the MCU and PHY on clock signal.

author: berke
author_rank: Frequent Contributor
timestamp: January 10, 2024, 10:25:17 am
content: I haven't integrated PHYs myself before but there are lots of extremely competent people in this forum, they will help you if you but you need to provide details. Is this your own board? How about the network stack? What's the OS if any? Can you give a schematic of what's around the PHY, maybe a picture or two?I don't understand what you mean when you say that you run the "STM32/PHY off of one channel of a function generator", do you mean that you provide the XO/XI clock from your siggen? Is your PHY clock 25 MHz or 50 MHz? And how do you relate that to the data clock?Normally the data clock is recovered by the receiver from the signal itself, but the signal you've captured is very dirty and the edges are hard to see. To me it looks like possible reflections from improperly terminated lines. How did you connect the PHY to the transformer? Is the transformer loaded, i.e. was the port connected as you were probing? I would tap the twisted pair directly.The green differential signal should be somewhat stable when you're going to sample it, but neither the falling nor the rising blue edges seem to provide a good time for that.I think you probably have identified start of transmission correctly as the differential voltage is zero before, in which case it is obvious from the waveform itself (regardless of the blue signal) is not a valid packet preamble with 7 AA's.

author: PDP-1
author_rank: Contributor
timestamp: January 11, 2024, 08:10:23 pm
content: Thanks for the replies!A bit of new data to report first, I captured an incoming packet and compared it to my outgoing packet with the time axes lined up to the same trigger (file tx-rx.png). The incoming packet looks like what would be expected - a preamble of 7 bytes of 0xAA followed by one of 0xAB and then the payload starts off with 0xFF because it is a broadcast packet. That gives us a reference to compare to the Tx packet (blue) which starts off fine for the first byte or so but then goes crazy and eventually stalls at an illegal voltage level for a while before going to zero. That is really strange since the PHY is supposed to be in charge of that bit sequence. I checked the power lines near the PHY and don't see any evidence of them drooping during a packet transmission. I had four prototype boards made for this run, I tested a second one and got the same result.Quote from: bson on January 09, 2024, 09:14:29 pmIf this were happening there should be some activity on the Rx lines when the Tx lines start to transmit since this is a full duplex connection, correct? I don't observe any such Rx signals associated with my Tx packets.Quote from: selcuk on January 09, 2024, 09:52:20 pmI included the PHY schematic, named signals go directly back to the microcontroller pins. There used to be some ESD protection on the Tx/Rx differential pairs but I removed it in case it was the cause of the problem. I derive a 50MHz signal from the microcontroller clock and send it out the MCO2 pin, this signal feeds both the PHY and the ETH_REF_CLOCK on the microcontroller side of the RMII connection. 50MHz is ~6m wavelength in air so maybe ~2m wavelength on the PCB and all the relevant components on the board are within 5cm of each other so there should not be a large phase difference.Quote from: berke on January 10, 2024, 10:25:17 amYes, this is my own board. It's the first time I've tried to integrate a PHY. The network stack is my own, it works fine on a Nucleo-F429ZI dev board and is set up to just transmit an ARP probe broadcast packet to a non-existant computer every 100ms for testing purposes. When I port it to my own PCB on an F427 everything works as expected right up to the MDIO registers. The PHY chip is different on the dev board (LAN8742A) but I stick to the basic registers that should be common to all PHY chips of this type. No OS, just baremetal C/C++. I've attachedQuote from: berke on January 10, 2024, 10:25:17 amI was using the high speed internal (HSI) clock as the base clock for my whole system when I encountered the problem with the PHY. This got me thinking that the HSI clock may not be accurate/stable enough and could be causing timing errors, so I used a function generator to drive the high speed external (HSE) pin since that should be much more stable. The clock tree diagram from Cube MX is attached. Then I used the MCO2 pin to drive both the PHY and data clock at 50MHz as described above.Quote from: berke on January 10, 2024, 10:25:17 amThe connection was PHY->magnetics->Ethernet Cat5E cable ~1m long->Netgear switch. I trimmed off a few cm of the outer jacket of the Ethernet cable and tapped into the twisted pairs at about the midpoint of the cable. I don't have a proper differential probe so I'm sure the scope lines can be loading things down and causing reflections. Also my scope is only 200MHz bandwidth so it may be rounding off edges on the clock lines.

author: berke
author_rank: Frequent Contributor
timestamp: January 11, 2024, 09:39:03 pm
content: Thanks for the details. I didn't find anything wrong, except maybe one thing. I know the waveform bit timing seems OK for 10 Mb/s but are you sure you managed to configure it for 50 MHz mode? Section 3.3.2 isn't very clear. Maybe you have to drive the strap-in pins AND write to register 1F.If that's all good my money would be on a software issue. You say it works with the other PHY but there could be some anomalous behaviour that one chip tolerates but not the other.