• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 34 subscribers
  • Views 656 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: Connection procedure

Shunsuke Nagata
Genius 13070 points
Part Number: DP83822I

Hi,

My customer run the below link-up sequence but Link-up may not success. (He judges the link-up status from interrupt and 0x0010 register)

Could you please give me advice which user sequence should be changed to success link - up?

I think it is strange which the interrupt is happened after #5. Please check if procedure for 4. disable auto-negotiation and 5. Set interrupt is correct.

Below is customer procedure to link-up:

1.Reset PHY
phy_write 0x00 0x8000(PHY Software Reset)
phy_read 0x00   -> 0x3100

 

2. Check PHY vender
phy_read 0x02   -> 0x2000
phy_read 0x03   -> 0xA240

 

3. Auto negotiation
phy_read 0x04   -> 0x01E1
phy_write 0x04 0x5E1 (Advertise asymmetric pause ability, …)
phy_read 0x04   -> 0x05E1

 

4. Disable auto-negotiation
phy_read 0x00   -> 0x3100
phy_write 0x00   -> 0x2100(100F)

 

5. Set Interrupt
phy_read 0x12   -> 0x6400 (Change of energy detected, Change of link status interrupt is pending, Auto-negotiation complete interrupt is pending.)
phy_read 0x11   -> 0x0108 (5 nibbles FIFO, Normal operation is 1 logic and during interrupt is 0 logic.)

 

-------------------------------------------------------
--- Interrupt is happened after #5 steps --- 

phy_read 0x10   -> 0x4994 (MDI Pairs swapped, False Carrier event has occurre, A new Link Code Word Page has been received, Indicates that and internal interrupt is pending, Auto-negotiation complete, Full-Duplex mode)
phy_read 0x12   -> 0x0600 ( Change of energy detected, Change of link status interrupt is pending)
phy_read 0x11   -> 0x0108

 -------------------------------------------------------

 

6. Set interrupt ( Continue from #5 step)
phy_write 0x11 0x0003 ( Interrupt Enable, Interrupt Output Enable)
phy_write 0x12 0x0024 (Enable interrupt on change of link status, Enable Interrupt on Auto-negotiation complete event)

 

7. Start Auto negotiation
phy_write 0x00 0x1200 (Auto-Negotiation Enable, Restart Auto-Negotiation)

… Customer expects Interrupt will be happened after Link – up. But the interrupt be never happened after #7.  

 

For Auto-MDIX, customer set the 28 pin (RX_ER) in bootstrap and Mode4. As he checed 0x0019 register, It is 0x8001(Auto-MDIX Enable, Phy Address 0x01)

Regards,
Nagata.

  • 0
    TI__Mastermind 18425 points
    Hi Nagata-san,

    Why is auto-negotiation disabled in step 4?
    Can you ask customer to try Step 1,2,3,5,6,7? Remove step 4. In Step 7, instead of 0x00 = 0x1200 try 0x1F = 0x4000 to perform soft refresh.

    -Regards
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    TI__Genius 13070 points

    Hi, Aniruddha -san,

    It could not be link -up as user run 1->2->3->5->6->7 procedure. And unexpected interrupt is happened after #5.

    User read 0x11 and 0x12 register in step 5 to clear interrupt status. Is it correct?

    Could you please let me know the another idea or recommend procedure to link up?

    ( If you would like to know specific register, could you please let me know ?)

    Regards,
    Nagata.

  • 0 in reply to Shunsuke Nagata
    TI__Genius 13070 points

    Aniruddha -san,

    Could you please give me your advice to confirm what is problem in this procedure?

    e.g. user should use default boot strap setting to detect if the procedure has problem or his hardware setting has problem.
    Or ask try TI recommend procedure to user.

    Regards,
    Nagata.

  • 0 in reply to Shunsuke Nagata
    TI__Mastermind 18425 points
    Hello Nagata-san

    It looks like there are some interrupts are already recorded in the interrupt status bits. Can you try reading the interrupt after enabling them in step 5? This will clear any previous interrupts and then the interrupts should behave normally.

    -Regards
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    TI__Genius 13070 points

    Hi, Aniruddha -san,

    Customer use 2.2k ohms pull-up resistor for INT/PWDN pin. With this setting, he confirmed the voltage of the pin would be 2.6V from 3.3V when he insert ethernet cable. And the voltage will be 3.3V from 2.6V after reading 0x12. That mean is the INT/PWDN_B pin shift from 2.6V to 3.3V and 3.3V to 2.6V. a controller SOC cannot detect the 2.6V <-> 3.3V. It seems that this is the reason why he cannot detect interrupt after auto-negotiation (Step.7)

    Should user not use pull-up resistor at INT/PWDN? ( He already checked the pin achieve 0V <-> 3.3V if he remove the pull up resister.)

    Regards,
    Nagata.

  • 0 in reply to Shunsuke Nagata
    TI__Mastermind 18425 points
    Hi Nagata-san,

    When the INT/PWDN pin is working as interrupt pin then it has a open drain output with weak pull up. Whether or not a external pull up is required depends on the application since this pin will be shared with SOC. If removing the external pull up helps solve the problem them I would recommend using that as a solution. There might be a internal pull up in the SOC and the combined pull up resistance is too strong for the PHY to overcome which can result in the problem that you described above.

    -Regards
    Aniruddha
  • 0 in reply to Aniruddha Khadye
    TI__Genius 13070 points

    Hi, Aniruddha -san,

    Thank you very much for your supports.

    Customer get the interrupt after step.8. and can send / recieve data. But he reported Link status (bit 0 in 0x0010 PHY Status register) still be 0.

    Do you have an idea why Link status = 0? (or is his procedure not correct?)
    Could you please help me this phenomenon?

    The procedure are
    1. Reset PHY
    2. Check PHY vender
    3. Auto negotiation
    4. Disable auto-negotiation
    5,6. Set interrupt
    7. Start Auto negotiation
    8. Interrupt
       ---> Read Link status bit

    Regards,
    Nagata.

  • 0 in reply to Shunsuke Nagata
    TI__Mastermind 18425 points

    Hi Nagata-san,

    As per our offline discussion, it seems that there is a separate issue at the customer. Can you post a new question with the relevant details? You can assign the new E2E post directly to me.

    -Regards

    Aniruddha

  • 0 in reply to Aniruddha Khadye
    TI__Genius 13070 points

    Hi, Aniruddha -san,

    No. The topic we tolked in offline is issue in this E2E post. The link status bit in  0x0010 register is cleared even if sending and recieving data are sucessed.

    Below are the infomation:

    - 0x0010 register :
    There are three type of register value when he read in #8 procedure.
    Case 1: read value = 0x4715( Link status : 1 (Valid link established))
    Case 2: read value = 0x4F15 ( Link Status : 1(Valid link established))
    Case 3 : read value = 0x4F14 ( Link Status : 0(Link not established))

    When Case 3, user read 0x0001 register, the value = 0x7869(Link status: 0(Link not established)) and read 0x0010 register again, the value changed to 0x4F15 ( Link Status : 1(Valid link established)).

    - 0x0001 register :
    There are two type of register value when he read in #8 procedure.
    Case 4: read value = 0x786D (Link Status : 1(Valid link established))
    Case 5: read value = 0x7869 (Link Status : 0(Link not established))

    When Case 5, user read 0x0001 register, the value = 0x786D (Link Status : 1(Valid link established)).

    When Link stauts is 0, the link status bit in 0x0010 and 0x0001 register would be set after user read 0x0001 register.

    Is it possilbe to anaysis why the Link status is cleared even if sending and reciveing data works correctly with above situation?

    Regards,
    Nagata.

  • 0 in reply to Shunsuke Nagata
    TI__Genius 13070 points

    Could you please support this?

    Regards,
    Nagata.

  • 0 in reply to Shunsuke Nagata
    TI__Mastermind 18425 points

    Link Status bit is latch low bit which needs to be read twice. It might happen that link is established and link LED is on but link status bit will show 0 on the first read. Reading the link status bit two-three times will give the correct link status value.

    -Regards

    Aniruddha