• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 34 subscribers
  • Views 1254 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83822I: facing an issue with the Link status bit in BMSR(0x0001) register

ANIKET
Prodigy 340 points


Hi,

We are using the DP83822IFRHBT PHY device in our development for Ethernet interface. We have configured the PHY into 100BASE-FX mode and facing an issue with the Link status bit in BMSR(0x0001) register.

 

Our observation is, by default on startup the link status bit is ‘0’ when no SFP is connected. Then connected the SFP alone for the first time into PHY and observed the Link status bit in BMSR(0x0001) register has changed to 1. From now onwards, the Link status bit is not changing for the corresponding SFP plug-out/plug-ins OR cable plug-out/plug. The Link status bit in BMSR(0x0001) remains to be 1.

 

Bootstrap setting are as follow,

COL = Mode 3(FX_EN =1)

RX_ER = Mode 4(SD_EN = 1)

LED_1(pin 24) = Default in low state, goes high when cable is plugged in.

 

The register values read after startup are,

RegAddr=0x000, value=0x2100

RegAddr=0x001, value=0x7849                  -> After first time plug-in of SFP, the value got changed to 0x784d

RegAddr=0x010, value=0x4

 

Could you please help us on this issue.

Regards

  • 0
    TI__Mastermind 18425 points
    Hi,

    Are you using the Signal Detect pin in your application? Is it connected from the SFP to the PHY?

    Are you reading register 0x01 twice after every time cable is reconnected?

    -Regards,
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    Prodigy 30 points
    Hi Aniruddha,

    Are you using the Signal Detect pin in your application? Is it connected from the SFP to the PHY?
    - Yes, we are using a Signal detect pin from SFP (which is called LOS - Loss of signal pin). We are connecting this to LED_1 of DP83822IFRHBT. This pin toggles High/Low with cable plug-in/plug-outs respectively.

    Are you reading register 0x01 twice after every time cable is reconnected?
    - We have a MII monitor task running periodically, which reads the register 0x01 for link state change. Here we are reading the 0x01 register twice, but no change is observed in the bit 2 of 0x01 reg.

    How can we know the cable is plugged in or plugged out to read the 0x01 register twice, without Link status getting updated.

    Regards,
    Sravan
  • 0 in reply to sravan alle
    TI__Mastermind 18425 points
    Hello Sravan,

    If the SFP supports LOS of signal, can you try changing bit 0 of register 0x465 to change the polarity of the SD pin?

    -Regards,
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    Prodigy 30 points
    Hi Aniruddha,

    We did change the polarity of the SD pin to '1' OR '0' in bit-0 of register 0x465 and verified that Link status bit of register 0x01 is not changed for the cable plug-in/plug-out.

    Regards,
    Sravan
  • 0 in reply to sravan alle
    TI__Mastermind 18425 points
    Hi Sravan,

    Can you share the schematics for the Ethernet section?

    -Regards,
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    Prodigy 30 points

    Hi Aniruddha,

    One more question:
    We have given the PHY address as 3 by doing the hardware strapping options in PHY_AD[0-4] of COL and RX_D[0-3] pins. And could able to read the same address from the PHY.
    But, when we read the "strap latch-in register (0x0467 and 0x0468), it is giving wrong values. Since these registers are extended registers followed the steps mentioned under section "8.4.2.5" in data sheet.

    Below are the values read from 0x0467 and 0x0468,
    0x0467 : 7f4f ---> This indicates the bits 01(RX_D1) 11(RX_D0) 11(COL) 11(RX_ER) 01(CRS) 00(RX_DV) 11(Reserved) 11(LED_0)
    0x0468 : 5 -----> This indicates the bits 01(RX_D3) 01(RX_D2)
    From the above values read the PHY address is different. Similar behavior is observed for other pins as well(Hardware strapping and register values mismatch).

    Could you please provide your inputs on this.

    Thanks,
    Sravan

  • 0 in reply to LeonardEllis
    TI__Mastermind 18425 points
    Hi,

    Is this issue open? I have sent a follow-up query offline over the email chain.

    -Regards,
    Aniruddha