This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83869HM: 1000M Media Converter mode. No errors detected but not ethernet traffic.

Part Number: DP83869HM
Other Parts Discussed in Thread: USB-2-MDIO,

Tool/software:

We cannot do a ping from both ends of the link. There is never answer.

Configuration:

- PHY on 1000BaseX to 1000BaseT conversion.

- Bootstraps: Auto-negotiation ON, 1000 Mbps, full Duplex on both sides of link 1000BaseX.

- Perform PHY register configuration sequence for 1000 Media mode converter (usb-2-mdio).

- 1000BASE-T of evaluation board connected to Gbit Switch. Computer, with 1000BaseT Card, also connected to this switch with address on same network.

- SW[4:1] = 0000 Normal operation.

What we observed?

- No errors are detected in the registers associated with the PHY. Led LD2, LD4 lights up solid green and LD6 flashes green.

-State 1000BaseX link: Auto-negotiation Complete, No Link Error. Seems there are Traffic: No always Rudi(/I) (idle) when make a ping.

-D1 Led (P1.0 y P1.1) lights is up (orange)

- We execute a ping from both sides of the network and no type of traffic is detected, with a wire-shark type analyzer
Any idea what our mistake is? I attach the values of the phy registers.














  • Hola Jesus!

    Thank you for providing the register log, this makes debugging the issue significantly easier. 

    From the registers I can see that:

    • Reg 0x1DF = 0x0044
      • which means you are in the correct mode, 1000Base-T to 1000Base-X Media Converter.
    • Reg 0x001 = 0x796D
      • which means that the copper link (1000Base-T) is good.
    • Reg 0xC01 = 0x6179
      • which means that the fiber link (1000Base-X) is not good. Please double check this before sending data

    Please see section 3.2 Fiber Communication of the DP83869 Troubleshooting Guide for more information.

    Regards,

    Alvaro

  • Thanks for responding so quickly.
    The values ​​of the registers that I uploaded to the forum were not well transcribed.

    I have rerun the test and obtained the values ​​again from the registers.
    (Values ​​that have changed are marked in red).
    I still don't know my configuration error. Can you give me some clue. Thank you

         

        

       


      

  • Hi Jesus!

    From the new register log, both Reg 0x1 and C01 are showing good link. From the EVM I also see that the LED_1 (fiber link) and LED_0 (copper link) are both lit. Are you still seeing communication issues? 

    Are you sure that the Fiber Link partner is communicating at 1000Base-X and not 100Base-FX? Both ends of the link need to be at the same speed, i.e. 1000 Mbps. Are you using a 850nm SFP Module?

    I grabbed and EVM and went into lab to check the functionality, was able to do media conversion with no issue.

    Not sure if it'll make a difference, but Reg 0x1DF = 0x4 in my testing.

    Regards,

    Alvaro

  • Following the instructions in document "Understanding different modes of operation in DP83869", 
    I have changed two bootstraps(LED1 and LED2 to VCC) and added the writing of the x01EC register to the routine (value 0x1FFC).
    I keep getting a link but I can't get data transmission.

    Register 0000 is: 1140 
    Register 0001 is: 796D 
    Register 0004 is: 0001 
    Register 0005 is: C1E1 
    Register 0006 is: 006D
    Register 0007 is: 2001 
    Register 0008 is: 6801 
    Register 0009 is: 0300 
    Register 000a is: 3800 
    Register 000D is: 401F 
    Register 0010 is: 5048 
    Register 0011 is: AC02
    Register 0012 is: 0000 
    Register 0013 is: 0000 
    Register 0014 is: 29C7 
    Register 0015 is: 0000 
    Register 0016 is: 0000 
    Register 0017 is: 0040 
    Register 0018 is: 6150 
    Register 0019 is: 4004
    Register 001A is: 0002 
    Register 001E is: 0012 
    Register 001F is: 0000 
    Register 0025 is: 0480 
    Register 002C is: 141F
    Register 002D is: 0000 
    Register 002E is: 0221 
    Register 0031 is: 10B1 
    Register 0032 is: 0050 
    Register 0033 is: 0000 
    Register 0037 is: 0001
    Register 0039 is: 0000 
    Register 003A is: 0000 
    Register 0043 is: 07A0 
    Register 004F is: 0176
    Register 0055 is: 1010 
    Register 006E is: 180C
    Register 0086 is: 0077 
    Register 0134 is: 1000 
    Register 0135 is: 0000 
    Register 0170 is: 0C0F 
    Register 0180 is: 0752 
    Register 0181 is: C850 
    Register 0182 is: 5326 
    Register 0183 is: A01E 
    Register 0184 is: E976 
    Register 0185 is: 19CF 
    Register 0190 is: 0000 
    Register 0191 is: 0000 
    Register 0192 is: 0000 
    Register 0193 is: 0000 
    Register 0194 is: 0000 
    Register 0195 is: 0000 
    Register 0196 is: 0000 
    Register 0197 is: 0000 
    Register 0198 is: 0000 
    Register 0199 is: 0000 
    Register 01A4 is: 0000 
    Register 01A5 is: 0000 
    Register 01A6 is: 0000 
    Register 01DF is: 0044 
    Register 01E0 is: 417A 
    Register 01EC is: 1FFC 
    Register 0C00 is: 1140 
    Register 0C01 is: 616D 
    Register 0C02 is: 2000 
    Register 0C03 is: A0F3 
    Register 0C04 is: 0020 
    Register 0C05 is: 41A0 
    Register 0C06 is: 0005 
    Register 0C06 is: 0005 
    Register 0C05 is: 41A0 
    Register 0C07 is: 2001 
    Register 0C08 is: 0000 
    Register 0C10 is: 3148 
    Register 0C18 is: 01FF 
    Register 0C19 is: 0000

  • Thanks Alvaro. 
    Yes, I am using an 850nM SFP module.
    At the other end it is connected to a xilinx zc102 evaluation board,
    I use an ipcore configured for 1000baseX at 1000mbps and fullduplex.













  • Hi Jesus,

    Everything on your DP83869HM looks good, how is the data being sent? The Xilink ZC102 is the link partner on the fiber end, who is the link partner on the copper end? What kind of data is being sent? Could we start off with a ping test? 

    Regards,

    Alvaro

  • Hello Alvaro,
    Thanks again for support.



    As we indicated, at one end we have the ZCU102. We have a Petalinux system set up. The MAC layer (PS hardware) is configured in fixed mode on system
    through Dts at (1000 Mbps Full-duplex).
    We do not have a connection, in this test, through MDIO from the operating system. We do the initialization of the PHY, in addition to the bootstrap, through the USB-to-MDIO software of a laptop.
    The PS GEM (mac layer) goes out to the programmable logic area of ​​the ZynqUS+, there we use a
    proprietary Xilinx ipcore "1G/2.5G Ethernet PCS/PMA orSGMII" for communication with the PHY in 1000baseX.
    Everything indicates that it is well configured (auto-negotiation, full-duplex, 1000baseX) and the
    feedback it gives us indicates that LINK is permanently OK,that auto negotiation has been completed
    and that no errors are detected.
    Regarding auto-negotiation (I have some doubts about what type of pause and the next page, they may not
    be configured the same at both ends, could the problem lie there?)
    In the other connection of the Phy board, the 1000baseT through RJ45, we have connected an 8-port TL-SG108E switch
    that supports 1000baseT. And, in another port of the switch we connect to a desktop PC with a LEMORELE #tc24 USB
    network card that supports 1Gbps Ethernet.
    On the desktop PC we have a Wireshark installed and we do not receive any frames from the ZynqUS+, both are
    configured on the same local network. At the operating system level of the zynqUS+, we send pins, we see that they go out through the GMII bus
    to the Xilinx ipcore but we do not receive anything at the other end. Is there any registers at the Phy of statistics, to know if something is really being received per 100baseX line?
  • Hi Jesus,

    Unfortunately no there isn't a register to check for fiber statistics, but we can try something else to debug this.

    Could you try setting:

    • Reg 0x01DF = 0x0000
      • Sets PHY into RGMII to Copper mode
    • Reg 0x0016 = 0x0020
      • Puts PHY into Reverse Loopback

    Once properly configured, the Linux machine running Wireshark can send data and the 869 will loop it back. The Linux Machine can then check if Packets sent = Packets received. This will confirm if the copper interface is working or not (I imagine that it is). If this works, then we know for sure the issue is with the fiber interface.

    Unfortunately, reverse loopback is not available for 1000Base-X. Do you have another fiber capable link partner to test the fiber communication with the ZCU102? This would help isolate the issue to either the 869 or the ZCU102.

    Regards,

    Alvaro