• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 166 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.

DP83825I: Difference of PHY reseting ways

GR
Expert 2831 points
Part Number: DP83825I

Tool/software:

Difference of PHY  reseting ways

Hello,

May I have question about PHY reseting way?

I think there is some way to reseting.

My customer is tested this:

A. Assert PHYRCR_Register bit 15 from Host processor

B. First assert Low RST_N pin, Second set PHYRCR_Register bit 14 from Host processor

These ways are same approach to reset digitalcore and registers.

However only B have issue that not link up after reset in rarely.

Compleatly same hardware, only change reset way B to A, The issue has solved.

Is there any difference in internal PHY controll, disital core operation, and so?

Thanks,

GR

  • +1
    TI__Mastermind 20512 points

    Hi GR,

    For case B, is host processor writing bit 14 while RST_N is low?

    Register reads/writes will not take effect while PHY is held in reset. Please see if case B has issues if writing PHYRCR bit 14 after RST_N is high.

    PHYRCR[15] is functionally the same as asserting RST_N low. PHYRCR[14] will restart the PHY's internal state machine - these sequences are both valid for full HW/SW reset:

    1) Reset by asserting RST_N low->high. Write 0x1F = 0x4000 after this hardware reset.

    2) Reset by writing 0x1F = 0x8000. Write 0x1F = 0x4000 after this hardware reset.

    Thank you,

    Evan 

  • 0 in reply to Evan Mayhew
    Expert 2831 points

    Hi Evan,

    Thanks for your information.

    Evan Mayhew said:

    For case B, is host processor writing bit 14 while RST_N is low?

    Register reads/writes will not take effect while PHY is held in reset. Please see if case B has issues if writing PHYRCR bit 14 after RST_N is high.

    It should be no.

    My customer is using though Linux kernel API.

    Functions of writeing PHY register should be re-write(send same command) if phy_write() retrun error(=mean can't write).

    Evan Mayhew said:

    PHYRCR[15] is functionally the same as asserting RST_N low. PHYRCR[14] will restart the PHY's internal state machine - these sequences are both valid for full HW/SW reset:

    1) Reset by asserting RST_N low->high. Write 0x1F = 0x4000 after this hardware reset.

    2) Reset by writing 0x1F = 0x8000. Write 0x1F = 0x4000 after this hardware reset.

    Do you have any need-delay-time between RST_N Low->high and writing PHYRCR[14] in 1)?

    And RST_N Low -> High and writing PHYRCR[15] is comleatly same operation?

    If there is information and difference (A and B way) of internal controll flow, Could you let me know?

    (If need NDA, please let me know. I will contact TI local sales)

    Thanks,

    GR

  • +1 in reply to GR
    TI__Mastermind 20512 points

    Hi GR,

    I see, so phy_write() will continuously write the register until the error is not returned? This is okay, as long as a write will occur after RST_N is high.

    GR said:

    Do you have any need-delay-time between RST_N Low->high and writing PHYRCR[14] in 1)?

    Yes, I recommend waiting at least 2ms after RST_N is high:

    GR said:

    And RST_N Low -> High and writing PHYRCR[15] is comleatly same operation?

    They are functionally similar for restarting the PHY, with one difference:

    Using RST_N pin will sample the strapped pins again to set PHY config to strapped values, while PHYRCR[15] will reset all registers to default values independent of straps.

    Both resets are valid methods for restarting the PHY, but RST_N is generally more consistent as it's not dependent on register access.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Expert 2831 points

    Hi Evan,

    Sorry to late reply.

    I understand.

    Thanks for the information.

    Best regards,

    GR