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: DP83869HM Tx error

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869

Hello,

I have a custom board with a DP83869 :

  • Connected with RGMII + MDC to the application processor
    • I am able to read/write all MDIO registers (std + extended set) from the linux
    • The IF is ok from the linux point of view (ip link up)
  • Connected to a 100Mbps SFP fiber module (Broadcom AFBR-57E6APZC)
  • Probing CLK_O, TX_CLK and RX_CLK give a clean 25MHz signal.
  • Probing the differential pair (SO_P/N) going to the SFP module give a 62.7MHz signal. This looks strange, but I don't know what I'm supposed to see the the IF is set up and idle
  • Register config :
    • GPIO_MUX_CTRL = 0x00BA (TDO=LED_GPIO)
    • LEDS_CFG1 = 0xD230 (led mode)
    • OP_MODE_DECODE  = 0x0012 (RGMII to 100Base-FX)
    • FX_CTRL = 0x2100 (100Mbps full-duplex)
    • GEN_CTRL = 0x4000 (soft restart)

Note that my linux driver configure OP_MODE_DECODE to 0x12 and not 0x42 as mentionned in the datasheet. However, the modified bit concern the RGMII <> SGMII bridge, and we are not in bridge mode.

When trying a ping from the linux, Tx and ERR LEDs blink. The ping command fails.

I didn't found any register to get any information about the error.

  • Does someone can confirm that my 100Mbps SFP module is supposed to work with the DP83869 ?
  • What about the OP_MODE_DECODE.BRIDGE_MODE_RGMII_MAC bit when using a 100Base-FX module ?
  • Is there any way to get some more information about the error ?
  • What am I supposed to see on the SO_P/N pin when IF is set and idle ?

Thank you so much :)

  • Hi Nicolas,

    1. I see that SFP module supports 100Base-FX, so this should work with DP83869.

    2. I believe that bit is only relevant when you are in bridge mode. If you are in RGMII to 100Base-FX, that bit should not affect the functionality.

    • For example, if you write 0x0042 rather than 0x0012, do you notice any difference?
    • Out of curiosity, why do you write 0x0012? If you only need to set the opmode, you could write 0x0002. With 0x0012 you are writing to a read-only reserved bit. 

    3. The best way to narrow down the issue is to perform loopback testing. This is described in section 2.5 of the DP83869 troubleshooting guide, and should be able to isolate the problem to the RGMII or the 100Base-X interface. To test the RGMII, perform MII loopback. To test the 100Base-FX, perform reverse loopback. We have a Fiber debug guide that can help with the 100Base-FX interface as well.

    4. In my experience, its difficult to discern much by probing the fiber lines directly. To debug a fiber connection, use the link status indicator, check the SD input of the PHY, and perform loopback testing.

    A few questions I have:

    • To confirm, the fiber link is up when you are pinging correct? If link is up on the DP83869 then the SD signal should be correct.
    • When performing MII loopback, does your MAC see the correct packets returning from the PHY?
    • Is the MAC able to receive packets from an attached link partner? In this case I'm wondering if you can send packets uni-directionally to test the TX path vs the RX path.

    Best,

    Shane