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

DP83826E: Startup Issue on PHY

Robert Czech
Prodigy 170 points
Part Number: DP83826E


Tool/software:

Hello TI-Support-Team,

Thanks for your help on our issues.

We are currently testing devices by doing multiple power cycles and then let a AM24xx System start up (using MDIO manual mode).

In some cases, it seams one of two PHYs (DP83826E) provide wrong information, when reading direct MDIO registers. With a logic analyser we could see that the data really exists on the MDIO/MDC lines.

Additional information:

- it seams previous operation with fixed communication setting Duplexity + Speed increases the possibility of the issue, instead of autonegotiation.
- the PHY varies from issue to issue PHY1 or PHY2 can have it
- the value received by indirect access varies also, another time it was  "0xFEFD"

Do you have an idea, what we can do to avoid this issue or you might have an idea in which cases the PHY coud send such data on direct request? 

Can you have a look on the following MDIO communication log?

Start-up
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0467 <-- Set Register SOR1
W:DP83826e addr:2 regnum: 0x000D with 0x401F
R:DP83826e addr:2 regnum: 0x000E with 0x0008 --> Read SOR1 --> Strap3(CRS/LED3)high --> PHYADD1 = 1 --> PHY Address is 0x2
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0468 <-- Set Register SOR2
W:DP83826e addr:2 regnum: 0x000D with 0x401F
R:DP83826e addr:2 regnum: 0x000E with 0x26A7 --> Read SOR2 --> CFG_AN_1 |CFG_AN_0 | CFG_AN_EN | CFG_AMDIX | LED_SPEED_POL | CFG_LED_LINK_POL | LED_2_POLARITY | RESERVED
--> Reserved should not be set?
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0467 <-- Set Register SOR1
W:DP83826e addr:0 regnum: 0x000D with 0x401F
R:DP83826e addr:0 regnum: 0x000E with 0x0002 --> Read SOR1 --> Strap1(CLKOUT/LED1)high --> Odd Nibble Detection enabled --> PHY Address is 0x0
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0468 <-- Set Register SOR2
W:DP83826e addr:0 regnum: 0x000D with 0x401F
R:DP83826e addr:0 regnum: 0x000E with 0x2E87 --> Read SOR2 --> CFG_AN_1 |CFG_AN_0 | CFG_AN_EN | CFG_AMDIX | CFG_LED_LINK_POL | LED_2_POLARITY | LED_3_POLARITY | RESERVED
--> Reserved should not be set?

// PHY2 is working in this case
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0303 <-- Set Register LED0_GPIO_CFG
W:DP83826e addr:2 regnum: 0x000D with 0x401F
R:DP83826e addr:2 regnum: 0x000E with 0x0008 --> Read LED0_GPIO_CFG --> reserved value for cfg_led0_clk_sel (1h) but cfg_led0_gpio_ctrl (0) = LED0
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0303 <-- Set Register LED0_GPIO_CFG
W:DP83826e addr:2 regnum: 0x000D with 0x401F
W:DP83826e addr:2 regnum: 0x000E with 0x0008 --> write back with changes but kept reserved bits
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0025 <-- Set Register MLEDCR
W:DP83826e addr:2 regnum: 0x000D with 0x401F
R:DP83826e addr:2 regnum: 0x000E with 0x0041 --> Read MLEDCR cfg_mled_en 1h = Value routed as per MLEDCR[6:3] --> 8h = LINK OK / BLINK on TX/RX Activity
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0025 <-- Set Register MLEDCR
W:DP83826e addr:2 regnum: 0x000D with 0x401F
W:DP83826e addr:2 regnum: 0x000E with 0x0041 --> Write Register with same configuration
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0305 <-- Set Register LED2_GPIO_CFG
W:DP83826e addr:2 regnum: 0x000D with 0x401F
R:DP83826e addr:2 regnum: 0x000E with 0x000E --> Read LED2_GPIO_CFG !! Default should be 0x0008 but cfg_led2_gpio_ctr = COL is set
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0305 <-- Set Register LED2_GPIO_CFG
W:DP83826e addr:2 regnum: 0x000D with 0x401F
W:DP83826e addr:2 regnum: 0x000E with 0x0008 --> write cfg_led2_gpio_ctr = LED2
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0460 <-- Set LEDCFG Register
W:DP83826e addr:2 regnum: 0x000D with 0x401F
R:DP83826e addr:2 regnum: 0x000E with 0x0565 --> Get LEDCFG LED0=LinkOK | LED2=100BASETX | LED3=10BASE-T | 5h = RESERVED RESET !! Defaut should be 0x5665h but in case of a running device same data is provided
W:DP83826e addr:2 regnum: 0x000D with 0x001F
W:DP83826e addr:2 regnum: 0x000E with 0x0460 <-- Set LEDCFG Register
W:DP83826e addr:2 regnum: 0x000D with 0x401F
W:DP83826e addr:2 regnum: 0x000E with 0x0555 --> write LED0=LinkOK | LED2=100Base-TX | LED3=100BASE-TX | 5h = Reserved Reset
R:DP83826e addr:2 regnum: 0x0018 with 0x0480 --> Read 18h directly LED Link Polarity=active High(strapping) | Blink Rate = 5Hz
W:DP83826e addr:2 regnum: 0x0018 with 0x0480 --> Write 18h directly Polarity=active High(strapping) | Blink Rate = 5Hz

// PHY1 failing in this case
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0303 <-- Set Register LED0_GPIO_CFG
W:DP83826e addr:0 regnum: 0x000D with 0x401F
R:DP83826e addr:0 regnum: 0x000E with 0x0008 --> Read LED0_GPIO_CFG --> reserved value for cfg_led0_clk_sel (1h) but cfg_led0_gpio_ctrl (0) = LED0
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0303 <-- Set Register LED0_GPIO_CFG
W:DP83826e addr:0 regnum: 0x000D with 0x401F
W:DP83826e addr:0 regnum: 0x000E with 0x0008 --> write back with changes but kept reserved bits
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0025 <-- Set Register MLEDCR
W:DP83826e addr:0 regnum: 0x000D with 0x401F
R:DP83826e addr:0 regnum: 0x000E with 0x1DEF --> Read MLEDCR
!! Reserved Bits set. - unexpected data -----------/---------------------/---------------------/---------------/
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0025 <-- Set Register MLEDCR
W:DP83826e addr:0 regnum: 0x000D with 0x401F
W:DP83826e addr:0 regnum: 0x000E with 0x1DC7 --> Write back modified registers
!! Modified data is still bad, because only unreserved/used bits have been changed -----------/---------------------/---------------------/---------------/
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0305 <-- Set Register LED2_GPIO_CFG
W:DP83826e addr:0 regnum: 0x000D with 0x401F
R:DP83826e addr:0 regnum: 0x000E with 0x0008 --> Read LED2_GPIO_CFG with the expected default
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0305 <-- Set Register LED2_GPIO_CFG
W:DP83826e addr:0 regnum: 0x000D with 0x401F
W:DP83826e addr:0 regnum: 0x000E with 0x0008 --> Write back to LED2_GPIO_CFG
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0460 <-- Set LEDCFG Register
W:DP83826e addr:0 regnum: 0x000D with 0x401F
R:DP83826e addr:0 regnum: 0x000E with 0x0555 --> Read LEDCFG Register, not the reset default, but the value set by firmware
W:DP83826e addr:0 regnum: 0x000D with 0x001F
W:DP83826e addr:0 regnum: 0x000E with 0x0460 <-- Set LEDCFG Register
W:DP83826e addr:0 regnum: 0x000D with 0x401F
W:DP83826e addr:0 regnum: 0x000E with 0x0555 --> Write firmware defaults
R:DP83826e addr:0 regnum: 0x0018 with 0x1DEF --> Read LEDCR(18h) directly
--> Bad data Read -----------/--------------------/----------------------/---------------/
W:DP83826e addr:0 regnum: 0x0018 with 0x1DEF --> Write LEDCR(18h) directly
--> Modified data is still bad, because only unreserved/used bits have been changed  -----------/--------------------/----------------------/---------------/
R:DP83826e addr:2 regnum: 0x0002 with 0x2000
R:DP83826e addr:2 regnum: 0x0003 with 0xA131
R:DP83826e addr:0 regnum: 0x0002 with 0x1DEF
--> Bad data Read -----------/--------------------/----------------------/---------------/
DP83826e addr:0 failed with 0x1DEF

ASSERT!  --> Restart of the System repeatedly (no self repair due to soft restart)

  • 0
    TI__Mastermind 25148 points

    Hi Robert,

    This is strange, the register access procedure looks correct to me.

    Register access for addresses 0x0 to 0x31 can be accessed directly without 0xD / 0xE procedure. If you can attempt direct access, please try writing / reading suspect registers.

    Does the design have external test points for MDC/MDIO? If so, I recommend using MSP-EXP430F5529LP to read the registers and isolate the issue to the AM24x SDK responsible for reads/writes.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 170 points

    Hi Evan,

    the issue did not occur all the time, multiple restarts are necessary until it happens. Each restart starts with 3 On-Off-Pulses of the power supply of the whole device.

    We have measured the MDIO with a logic Analyzer in case of the error.  The data is really on the MDIO lines (or do you think about a collision on the MDIO bus? Under these circumstances a test with the MSP Board might not help us, am I right)?

    In this measured case, the other PHY(Address 0x02) failed 
    DP83826e addr:2 regnum: 0x0002 with 0xFEFD (previous direct register accesses provide same data)
    DP83826e addr:2 failed with 0xFEFD
    DP83826e addr:0 regnum: 0x0002 with 0x2000
    DP83826e addr:0 regnum: 0x0003 with 0xA131


    In our setup the clock is concatenated from PHY1 (CLKOUT/LED1) to PHY2(XI), but only PHY2 (CLKOUT/LED1) is terminated(strapped) with 1k to ground. Would you recommend to strap CLKOUT/LED1 from PHY1 also with 1k to GND (Can this load be driven)? Is there an example circuit how to concatenate the clock of the PHYs correctly?

    In the Schematic Design Review a reset pulse of at least 1us is required, in our firmware we do a reset of 30us. In the Datasheet a minimum of 25us is provided. Which time do you recommend?

    Do you have any further idea which hardware issues (e.g. strapping) we should look at?
    I have read about a software reset for the digital part. Do you think it makes sense to assert this reset on every start to get the PHYs always to stable operation?

    I hope you can provide me some hints how I could get this stable.

    Best regards, 
    Robert

  • 0 in reply to Robert Czech
    TI__Mastermind 25148 points

    Hi Robert,

    Typical application for shared clock is:

    DP83826 (RMII master mode) has 25M crystal input on XI, outputs 50M clock on 50MHz_RMII pin

    DP83826 (RMII slave mode) receives this 50M clock on XI pin

    The clock connection from 50MHz_RMII -> XI should be direct without additional passives that may distort the clock.

    For your CLKOUT case, I am concerned about the strap resistor distorting the clock. Could we test with this resistor DNP'd for now?

    Robert Czech said:
    In the Schematic Design Review a reset pulse of at least 1us is required, in our firmware we do a reset of 30us. In the Datasheet a minimum of 25us is provided. Which time do you recommend?

    25us minimum is recommended, and 30us reset is good as a buffer for any edge cases.

    Robert Czech said:
    Do you have any further idea which hardware issues (e.g. strapping) we should look at?

    Could we verify the PHY address strapping to confirm there is no contention on the bus? Please share schematic so I can review Strap2/3/4.

    (e-mayhew@ti.com for private share)

    Register 0x19[4:0] can also be used to check strapped address.

    Robert Czech said:
    I have read about a software reset for the digital part. Do you think it makes sense to assert this reset on every start to get the PHYs always to stable operation?

    Yes, we have seen edge cases where writing 0x1F = 0x4000 will help the PHY reach stable operation by resetting internal state machine.

    This SW restart is typically applied as the last step of register configuration, but it can also be applied at the start.

    Thank you,

    Evan

  • 0 in reply to Evan Mayhew
    Prodigy 170 points

    We have found the issue. In this circuit it was a pulldown on the reset signal with only 10k. The internal pullup of the PHY is also 10k. So while the CPU pin mux is not yet configured the half voltage level was on the reset signal. Changing the resistor to 1k8 solved the issue for us.