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.

DP83TD510E: SPE link drops due to periodical reading of SQI (0x0A85) register

Part Number: DP83TD510E

Hello dear support team!

I have designed custom made board based on DP83TD510E to provide SPE link.
Board has:
* MCU for diagnostic purposes, to read or write DP83TD510E registers;
* LED for indication of SPE "link is good" status. Connected to the LED_0 pin of DP83TD510E;
* RGB LED for indication of SPE link health (Poor, Marginal, Good). Connected to MCU outputs.

My setup consists from two identical boards interconnected through SPE link.

The SPE link operate fine and no issues observed when I sequentially, each 500 ms, read registers:
* PHY_STS (0x010) - to get link status (link is up or link is down);
* dsp_reg_72 (0x872) - to obtain SQI value;
* alcd_metric (0xA9D) - just for debugging purpose;
* alcd_status (0x0A9F) - just for debugging purpose.

But, link goes down quite soon (after 5-20 sec) when I add 0xA85 register into reading sequence. Additionally, sometimes this lead to some unsynchronization of SMI bits transmitted by PHY (unforeseen activity of MDIO line during preamble time).

Questions:
1. Does register 0x0A85 has any limits on periodical reading or it has a bug in implemetation?
2. What values from dsp_reg_72 register corresponds to Poor, Marginal, Good thresholds? I want to use this register for SPE link health indication, because of its reading has no issues in contradiction to 0xA85 register.

  • Hi Igor,

    I recommend using register 0xA85 for SQI measurements, with link quality calculations and thresholds noted in this app-note:

    To clarify, link only goes down after 0xA85 is read? There may be an issue with the register read sequence as 0xA85 is in extended register space.

    Please share your complete sequence and compare to this example:

    Thank you,

    Evan

  • Thanks!


    I know already about access to extended registers and about Application Note.

    Yes, link goes down only when I add reading of register 0xA85 into sequence of communication with PHY.

    Communication with extended registers made exactly as recommended:

    mdio_read() start: phy=9, reg=0xA85
            smi_reg_write(): phy=9, reg=0x00D, data=0x001F
            smi_reg_write(): phy=9, reg=0x00E, data=0x0A85
            smi_reg_write(): phy=9, reg=0x00D, data=0x401F
            smi_reg_read():  phy=9, reg=0x00E, data=0x006B
    mdio_read() end: data=0x006B

    Complete log can be found at MDIO log.

    Here is some comments to the MDIO log:

    * Time=0.0: board power switched on.
    * Time=0.0 .. 4.690:     link is down
    * Time=5.20 .. 76.070:   link is up. Reg 0xA85 = 0x005B .. 0x006D
    * Time=76.630 .. 77.750: link is up. Reg 0xA85 = 0x16AE .. 0x411D
    * Time=78.310:           link is down

    In meanwhile, there was communication errors happened:
    * Time=7.440: PHY_STS register I/O error.
    * Time=57.230: PHY_STS register I/O error.
    * Time=58.860: PHY_STS register I/O error.
    * Time=73.930: PHY_STS register I/O error.
    * Time=75.560: PHY_STS register I/O error.

    "Link down" problem and I/O errors disappear if I replace access to 0xA85 register by 0xA9D.

  • It seems, source of problem is KSZ8864CNX Ethernet switch which is connected to same MIIM interface. KSZ8864CNX has non standard SMI protocol and this is probably makes conflicts.

    Issues disappeared when I have disconnected MDIO line of KSZ8864CNX from common MIIM interface.

    I will make long term testing to confirm this.

  • Hi Igor,

    Glad you found the source of the problem.

    We have not tested register access on DP83TD510-E using MIIM interface, so it's likely the MIIM protocol is causing an unintended configuration to be set on the PHY.

    Do you have access to an SMI controller? I recommend MSP-EXP430F5529 LaunchPad if you need an external controller for evaluation stage.

    Thank you,

    Evan

  • I maybe wrong on terminology. I mean DP83TD510E and KSZ8864CNX connected to same SMI bus.

    Re-connection of KSZ8864CNX to separate SMI bus resolve the issue.