DP83867CR: PHY generating RxDV traffic on the other end with autonegotiate turned off

Hi Joshua,

Can you please share the board schematic for review?

Which MAC interface are you using?

--
Regards,
Gokul.

No MAC.  An FPGA.  Here is the relevant portion of the schematic.  The named nets go to the FPGA.

Hi Joshua,

Thanks for sharing the schematic.

I did not find anything out of order in the schematic except that 10uF and 10nF caps are not present in the schematic. This might not be causing the issue under discussion, but it is better to mount them for better performance.

Please mount a pull up resistor of 2.2k on MDIO. SMI can misbehave in the absence of this pull-up resistance.

On the issue under discussion,

1. I guess you would have measured the voltage of the pin Tx_en of DP83867. Can you please confirm that the voltage is close to 0V?
2. Do you by chance have spare board of DP83867+FPGA? You can try replicating the same issue with 2 DP83867 so that we can isolate where the issue is.

--
Regards,
Gokul

Are the 10uF and 10 nF caps you mentioned for the X_I pin, or something else?

We plan on adding the pullup to MDIO on our next revision, but  in the meantime I do have the FPGA pin pull-up enabled for this (I think it is more like a 4.7 k or so).  

1. I have not directly measured TxEN, but when I use a loopback cable I do not get the unexpected RxDV activity on the DP83867. I only get the unexpected RxDV activity when hooking to another type of PHY.  I am using an fpga-based integrated logic analyzer to monitor the all of the Tx and Rx signals.  In fact, when looping back the read data matches the tx'd data perfectly.  

2. I do have other prototype boards I can try, I'll work on getting one in my test PC.  I won't be in the lab until next week though.

If I have the auto-negotiation turned off in the BMCR register what traffic should there be from the DP83867?

Thanks for the help so far! 

Joshua

Hi Joshua,

Glad to help!!

I recommend checking the voltage of TX_EN. This helps us understand if TX_EN is floating at a random voltage or being driven by FPGA. Once, we confirm that TX_EN is low, we can go and debug on the MDI side to check what is the issue.
I agree that if the loopback test is working, then TX_EN wouldn't have been floating. But it is better to check TX_EN.

Checking between 867-867 helps us isolate whether the issue is from the 867DUT or the interaction between 867DUT and other vendor PHY.

Disabling auto-neg and enabling 100M mode will make the PHY transmit MLT-3(data encoding of 100Base-TX) Idles on the line with no data.

I'll keep you posted if I could think of any other debug ideas.

--
Regards,
Gokul.

I did not get a chance to check the voltage of TX_EN (the card is slotted in and I didn't have time to find a way to tack a wire to that signal.  However, I did hook the DP83867 to another DP83867.  I was not transmitting from either board.  But on the board set up on the receive side I was seeing an RxDV transition for every RxCLK!  I don't get it.  

I do not see the rx data changing, it stays the same throughout.

Hello Joshua,

Can you please check if LED_1 is high and LED_2 is toggling on any of the DP83867 boards?

Can you please also check if TX_CTRL on link partner DP83867 is toggling?

--
Regards,
Gokul.

Hi Joshua,

Can you please let me know if you could resolve the issue?

--
Regards,
Gokul.

Thanks for getting back with me.  Another project has taken priority from this, so I have not done anything since my logic analyzer screenshot above.  I hope to return to this board in the next week or two.

Hi Joshua,

Thanks for the update. Please take your time and get back to me here with these observations.

--
Regards.
Gokul.