• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 1315 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

dp83865 issue

Vineetha Thomas
Prodigy 140 points
Other Parts Discussed in Thread: DP83865

Hi,

I am facing the following issue in using dp83865. Please see below the problem description.

I am following the following sequence to initialize the phy dp83865

  1. Master Clock is given to the PHY, at pin number 86 from a 25MHz oscillator.
  2. Bring the PHY out of reset. The PHY is brought out of reset by driving 1 on the reset pin (#33).
  3. Issue the software reset to the PHY by writing to MODECTL register. Wait for approx. 2sec after the software reset.
  4. Read the registers to check if link established. Link is established.
  5. Configure the registers to set the speed, duplex mode. (manual/forced mode).

 

Following is the register settings of the PHY as I read back through MDIO.

BMCR = 0x4100

BMSR = 0x7949

ANAR = 0x5E1

ANLPAR = 0x45E1

KTCR = 0x300

KSTSR = 0

KCSR = 0x3000

STRAP_REG = 0xC041

LINK_AN = 0x402

AUX_CTL = 0xA000

 

 Below is the description of the issues I face.

 1.      PHY fails to come out of software reset even after the prescribed time (20ms). This behavior is however intermittent.

2. When used in PHY loopback mode, the data received is consistently incorrect. I was not able to see any particular pattern in the incorrect data. I can see that the data sent out from the MAC to the PHY is correct.

3. When I try to transmit packets to a link partner, I can see no data received at the partner end. However, again, the MAC at the Transmitter is sending data correctly.

4. These issues are seen at all speeds, i.e, 10/100/1000.

5. I have verified the clocks, i.e, the Tx clock from the MAC and the Rx clock from the PHY.

6. At the other end, I am connecting to the dp83848 10/100 RMII phy. When connected to this PHY, I am testing for only 10/100 speeds.

 Could you please help with these queries

  1. Could you clarify on the use of MDIX mode, whether to use it or not.
  2. Could you please shed some light to what might be possible reasons for the above issues?
  3. Is there a driver for dp83865 available?

 Thanks,

Vineetha

  • 0
    TI__Mastermind 31600 points

    Vineetha,

    Based on the value of 0x4100 shown for the Basic Mode Control Register (BMCR), register address 0x00, it appears that the device is being configured for Loopback. Is this intended?

    I would suggest breaking the initialization down into steps.  Could you please provide the register values for the following scenarios:

    1. Power up the board without connecting to a link partner via a cable.
    2. Apply the reference clock at CLK_IN.
    3. Release the RESET_N pin.
    4. Read the registers.
    5. Connect the cable to the link partner.
    6. Read the registers. 

    Once we have a baseline on this functionality, we can look more closely at the software reset.

    Regarding your other questions, MDIX mode is generally recommended.  It is also strongly recommended that auto-negotiation be used for 1000Base-T applications.

    We do not provide a driver for the dp83865. 

    Patrick

  • 0 in reply to Patrick OFarrell
    Prodigy 140 points

    Hi Patrick,

    Thanks for the reply. I will try the initialization steps suggested by you soon and get back with the results. Meanwhile, I had another query.

    From the datasheet, there are two modes of RGMII, 3Com and HP. Could you clarify on how these are different? Also, is the difference applicable for all speeds 10/100/1000? My understanding is that both the PHY and the MAC used should follow the same protocol. Is that correct?

    Also datasheet says (section 4.6.2) "The DP83865 implemented the HP timing".  Whereas in page 55 datasheet says "The 3COM mode clock delay is implemented internal in the DP83865DVH." These two statements seem contradicting. Can youplease clarify on which timing (3COM or HP) should the MAC follow when used with the PHY?

    Thanks,

    Vineetha

  • 0 in reply to Vineetha Thomas
    TI__Mastermind 31600 points

    Vineetha,

    Meeting the RGMII timing requires delaying the transmit clock (RGMII_TCK) and the receive clock (RGMII_RX_CLK).  This can be accomplished by adding delay on the board, i.e. using longer traces for these clocks, or by enabling delays within the PHY. 

    For the DP83865, we refer to the case where delay is added on the board as "HP mode".  We refer to the case where delays are enabled in the PHY as "3Com mode".  Since 3Com mode results in a simpler board level implementation, it is generally preferable.

    Patrick

  • 0 in reply to Patrick OFarrell
    Prodigy 140 points

    Hi Patrick,

    Could you please also clarify on what is the exact delay achieved in the 3com mode?

    Regards,

    Vineetha

  • 0 in reply to Vineetha Thomas
    Prodigy 140 points

    Hi Patrick,

    Thank you for your clarification on the 3COM mode. I have identified that using 3COM mode eliminates the issue I initially reported in most cases. However, I have the following doubts regarding the RGMII timing spec given in the datasheet of the PHY dp83865 (section 6.5).

     1. TX to clock skew (at receiver PHY), in HP mode is given as 1.0 to 2ns. Now, the MAC at our end has a TX data to clock skew of -500ps to 500ps (which is as per RGMII spec). This will mean we need to implement a delay on board so that the requirement of 1.0ns to 2.0ns at the PHY end is met.

    Suppose we implement a delay of 1.5ns. Considering the lower limit of -500ps of the MAC, the TX to clock skew at the PHY for this delay would be -500ps + 1.5ns = 1ns (which is just at the limit expected by the PHY) . Considering the upper limit of 500ps of the MAC, the TX to clock skew at the PHY for this delay would be +500ps + 1.5ns = 2ns (which again is just at the limit expected by the PHY).

    For any delay below 1.5ns, this would violate the lower limit(1.0ns) of the PHY. For any value above 1.5ns, this would violate the upper limit (2.0ns) of the PHY. Even 1.5ns may not be a safe choice, since calculation shows it is just at the brim of the limits allowed by the PHY. Does this mean that I cannot use HP mode with my MAC? Or is there something missing in my understanding of the spec?

     Could you please clarify on this ASAP, as this will affect the design.

     2. For the 3COM mode, the table in section 6.5 of datasheet says RX to clock set up at transmitter PHY, is 1.4ns (minimum). Why is no maximum value specified here?

    The MAC at our end expects data to clock skew of 0.9ns to 2.6ns (again, as per RGMII spec). Assuming we do not implement any delay on board for the 3COM case of the PHY,   RX to clock set up of 1.4ns at the PHY will work for us (since it is within 0.9 to 2.6ns). However, if the RX to clock set up at PHY happens to be above 2.6ns, then this will cause failure. Hence I am worried about the maximum limit of the RX to clock set up at PHY. Please clarify.

    Thanks,

    Vineetha