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.

DP83867E: DP83867E new design bringup

Part Number: DP83867E

New design using DP83867ERZ.

No special strapping options, all are default/open.

The device does not attempt auto-negotiation at power up as expected, I've reviewed all the basic stuff and haven't found anything wrong.

When again review the strapping option pins, specifically for RX_CTRL, it would seem that MODE 1 is N/A and has a special note "(1) Only Mode 3 and 4 are valid for RX_CTRL. Mode 1 and 2 are not applicable and should not be used"

Since MODE 1 is the default strapping option (ie: no reisistors), then how can this be N/A?

Further NOTE for RX_CTRL is:

Strap modes 1 and 2 are not applicable for RX_CTRL. The RX_CTRL strap must be configured for strap mode 3 or strap mode 4. If the RX_CTRL pin cannot be strapped to mode 3 or mode 4, bit[7] of Configuration Register 4 (address 0x0031) must be cleared to 0

Since bit 7 of Configuration Register 4 is defined as RESERVED and reads back '0', does the note about clearing this really apply.


Was/Is there a bug/errata in regards to the strapping option on the RX_CTRL pin (if I read between the lines it seems there is)

 

Thanks

Jeff

  • Hi Jeff,

    The DP83867E has a hidden strap mode that does not work correctly. This is why you need to configure the RX_CTRL signal for MODE 3.
    If you do not strap it for that, then you do need to set bit[7] in register 0x31 to disable the incorrect strap. Even though the DS says RO and RESERVED, this must be done if not strapping to MODE 3. I will inform my colleagues to remove the RESERVED note and the RO note in the register.
  • Can you elaborate on what this ‘hidden’ strapping option controls?

    Could this be why the PHY doesn’t attempt to start auto-negotiation?

    We are also having some issue in that the PHY seems to think it's in SGMII mode even though it should be in RGMII mode

    Thanks,
    Jeff Ross
  • Ross,

    Can you reply to my follow up questions?

    Thanks

    Jeff

  • Hi Jeff,

    To the PHY is thinking it is in SGMII operation because it must be strapping to SGMII operation. Are you tying LED_0 HIGH on your board?
    Can you explain how LED_0 looks on your board?
    LED_0 needs to be in either MODE 0 or MODE 3 for it to not be in SGMII operation.

    I am sorry but I cannot elaborate on this strap mode. For proper operation RX_CTRL needs to be in MODE 3 as described in the datasheet.
    If not, you can use the register access method.
  • I've figured out the SGMII issue (LED_0 is being held up during the time the straps are latched).

    Can you just confirm if the invalid MODE_0 in RX_CTRL is affecting the auto-negotiation? (No need to elaborate on the broken hidden strap option)

    I see that the earlier datasheet did not have this restriction and so the default 00 should have worked, not much good having a default value that is broken :)

    For the register 0x31  bit[7] operation, you stated above that we need to set bit 7, however the datasheet says to clear bit 7, which is correct?

    Do we need to issue a soft reset after the mystery bit 7 operation?

    Thanks

    Jeff Ross

  • Hi Jeff,

    Covering for Ross here as he is OOO.

    The RX_CTRL strap does control auto-negotiation, as shown in the DS. Mode 2 and mode 4 of RX_CTRL disables auto-negotiation entirely.

    Mode 1 and Mode 3 enables auto-negotiation. Auto-negotiation, cannot be re-enabled by register once it is disabled by strap! AN enabled is NOT dependent on reg 0x31 bit[7].

    If your DP83867 is not sending out FLP, and attempting to auto-negotiate with a link partner, then the RX_CTRL pin is likely going into mode 4 by being pulled up during initialization of the PHY. It could also be going into mode 2, but this is less likely as that's an intermediate voltage.

    Register 0x31 bit[7] only remedies the possibility of link instability with certain link partners.

    Best Regards,
  • We've now got auto-negotiation working, can you please just clarify my question from my previous post:

    For the register 0x31  bit[7] operation, you stated above that we need to set bit 7, however the datasheet says to clear bit 7, which is correct?

    Do we need to issue a soft reset after the mystery bit 7 operation? (saw this elsewhere on the Forum in regards to this register change)

  • Hi Jeff,

    Sorry, you need to clear 0x31.7 as shown in the DS.

    After bit[7] is cleared, restart auto-negotiation or do a soft reset.

    Best Regards,