• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 35 subscribers
  • Views 296 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.

DP83867IR: Regarding communication errors when using the DP83867IR in combination with a switching hub whose IFG is less than 96ns.

mitsuda Kenji
Prodigy 10 points

Part Number: DP83867IR

I am using a 1000base-T board equipped with a DP83867IR in combination with a switching hub from a certain manufacturer. In frames output from the hub, the IFG sometimes falls below the specified minimum value (96ns), resulting in a communication error. When I changed the DP83867IR register (VTM-CGF address 0x0053) from its default value of 0x5 to 0x3, a different error occurred. I would like to know the cause of this error and how to resolve it.

Also, does the DP83867IR have an EEE (Energy Efficient Ethernet) function? If so, please tell me how to disable this function.

  • 0
    TI__Mastermind 26771 points

    Hi Kenji-san, 

    What error occurs when the register 53h is modified?
    DP83867 should not be advertising EEE mode except for 10M. Does it go into EEE mode?

    Best,
    J

  • 0 in reply to J
    Prodigy 10 points

    Hi J-san,

    Which registers should I check to find out the details of the error?

    The information regarding EEE mode is based on AI-generated research, and it is unclear whether the system actually operated in EEE mode.

    Best regards

  • 0 in reply to mitsuda Kenji
    TI__Mastermind 26771 points

    Hi Kenji-san, 

    You mentioned you are getting a different error when 53h is changed. I want to know what error you initially saw and what the different error is when you make the register change. 

    DP83867 does not support EEE. 

    Best,
    J

  • 0 in reply to J
    Prodigy 10 points

    J-san,

    Before register change: On certain hubs (e.g., NETGEAR GS105E), an IFG violation (IFG violation) was detected CRC error when the IFG was less than 96ns.

    After register change: Even on hubs that previously had no problems (IFG > 96ns), CRC errors are now occasionally detected.

    The CRC error is checked using the MAC status. Please let me know if there are any registers on the PHY that allow for more detailed information.

    Best regards,

    Kenji

  • 0 in reply to mitsuda Kenji
    TI__Mastermind 26771 points

    Hi Kenji-san, 

    Thank you for the detail. Have you tried setting register 53h to 2054h instead of 2053h? Typically, we ask customers to try 4h before 3h. 
    How long is the cable between the hub and the PHY? 

    Best,
    J

  • 0 in reply to J
    Prodigy 10 points

    J-san,

    The error disappeared after changing the value of register 53h to 2054h.

    What is the relationship between the register value and IFG?

    Also, what could be the reason for the error occurring at 2053h?

    Best regards,

    Kenji

  • 0 in reply to mitsuda Kenji
    TI__Mastermind 43615 points

    Hi Kenji-san,

    I will be taking over for J. This register control a threshold for detecting IPG in ethernet communication. Typically, we have seen no issues with customers going with 0x2054 or 0x2053. If errors disappear with 0x2054, I recommend we keep the value and move forward with your evaluation.

    Sincerely,
    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 10 points

    Gerome-san,

    We will proceed with the evaluation at 0x2054.

    However, we would like to know the IPG detection threshold times for 0x0255, 0x2054, and 0x2053.

    We would also like to know the cause of the error at 0x2053.

    Best regards,

    Kenji

  • 0 in reply to mitsuda Kenji
    TI__Mastermind 43615 points

    Hi Kenji-san,

    We are unable to provide this information as this is internal design information. All I can say is that adjusting this field assists with the threshold at which how many bits are satisfactory during the IPG period before an excursion causes an idle error.

    It is our understanding the setting LSB field to 0x3 instead of 0x4 would provide equivalent or better performance, so this error at this field is unexpected. Please proceed with evaluation at 0x4 and see if there are any other issues that show up in your validation.

    Sincerely,

    Gerome