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.

DP83822IF: Not recognized by downstream EtherCAT device

Part Number: DP83822IF

Hello, 

I am using the DPP83822IF with a LAN9252 over an MII interface. We have confirmed that MII works in loopback mode and the run LED lights up.  We have confirmed hard straps on COL enable fiber. Fiber enable was confirmed again by checking registers.  Our downstream device does not recognize the DP83822 PHY. Is there any reason why this would be the case that we are missing? 

Thanks.

  • Hi Rachel,

    Could you share a block diagram of the application, and a register dump from 0x0 to 0x1F, and 0x467/468 so I may confirm the device configuration and status?

    Thank you,

    Evan

  • Hi Evan, 

    The register dump is as follows: 

    0x00: 0x3100 0x7849 0x2000 0xA240 0x0181 0x0000 0x0004 0x2001 0x0000 0x0000 0x4100 0x1000 0x0000 0x0000 0x0000 0x0000
    0x10: 0x0204 0x0108 0x0000 0x0000 0x0000 0x0000 0x0100 0x0045 0x0400 0x8020 0x0000 0x007D 0x05EE 0x0000 0x0002 0x0000

    0x467: 0x07CF
    0x468: 0x0000

    The block diagram is below: 

    Thanks, 

    Rachel

  • Hi Rachel,

    Thank you for sharing the diagram and register dump - it looks like auto-negotiation is failing, there are some hardware and software checks to help diagnose.

    Please try writing 0x1F = 0x4000 on DP83822 to update the link status.

    Is auto-negotiation enabled on LAN9252 with 100M advertisements? Can you also share the SFP module model# used at each endpoint?

    Thank you,

    Evan

  • Hi Evan,

    I'm on Rachel's team, so I'll hop in here and help out. I just tried setting that register with no noticeable change. The SFP module we're using at both ends is the 100BaseFx-SFP-31. 
    Regarding auto-negotiation, my understanding was that it was not supported when using 100Base-FX.I have tested using Enhanced Link Detection, both enabled and disabled, with no noticeable results. We can also reset the PHY and ESC individually and have tried different reset cycles/timing with no improved behavior. 

  • Hi Lincoln,

    Evan is out on Time bank until Tuesday, March 5th. Please allow him until then to continue supporting you.

    Regards,

    Alvaro

  • Hi Lincoln,

    Thanks for sharing the result details.

    Could you share the schematic with me so I may review? (email to e-mayhew@ti.com for private share if needed)

    I just tried setting that register with no noticeable change

    After writing 0x1F = 0x4000, did register 0x1 value remain the same (0x7849)?

    Best regards,

    Evan

  • Yes, the register value stayed the same. I have emailed you the schematics of this subcircuit as well.

    Thanks for the help,
    Lincoln 

  • Thank you. I will review and get back to you with possible causes. Please expect feedback by Monday 3/11 at the latest.

    Regards,

    Evan

  • Hi Lincoln,

    I have some clarifying questions:

    • What is the downstream device? Is it the same DP83822 setup? If so, please share a register dump for this device as well while attempting to link.
    • Is there any case with link status up while testing?
    • Can you help me understand the clocking scheme? I see TX_CLK on DP83822 is floating, is the ESC <-> DP83822 connection only referenced to "MII_CLK25"?

    Thank you,

    Evan

  • The downstream device is a Microchip LAN9252. We've been treating it as a working "black box", since it has worked as a downstream device with other setups (not using the DP83822). 
    The link status up LED on the PHY does turn when loopback mode is enabled, that is the only time we've seen that light on. We have seen a downstream link detect (with no data) when the PHY is 100Base-Tx mode, however I don't think that's particularly indicative of anything, as we are using FX.
    Yes, the TX_CLK is floating and the phy is referenced just from the MII_CLK25,which is in accordance with the datasheet of our MAC (LAN9252) - i attached an image for reference . We have also tested with the MII_CLK25 reworked to connect to TX_CLK as well though with no success.

  • I have a few suggestions to help isolate where the signal chain may be failing.

    To validate MAC side:

    - Enable MII loopback on DP83822 (0x0[14] = '1')

    - Sending packets from LAN9252 or upstream host, verify these packets are looped back over DP83822 MII.

    To validate MDI side:

    - Enable reverse loopback on DP83822 (0x16[4] = '1')

    - Transmitting packets from downstream LAN9252 over fiber to DP83822, verify these packets are looped back over DP83822 MDI.

    Also, is it possible to test with another DP83822 used as the fiber link partner? I am curious to see if link status is high in this case (after 0x1F = 0x4000).

    Thank you,

    Evan