Hello Team
can you please help with the following issue:
"Our device with the integrated DP83867 module is connected to a second end device (only supporting 100Mbit/s).
During the power cycle, the DP83867 module is supposedly disturbed and hangs up. This can be recognized
This can be recognized by the fact that the link LED of the DP83867 no longer goes out when the cable is disconnected --> here the PHY no longer seems to change the link.
to change the link. Everything continues to work on the remote station without any problems (link up and down works). In addition
the internal registers of the DP83867 can still be accessed. However, they only provide implausible static values. A SW reset
via the registers has already been attempted and is not processed by the PHY."
Question already answered from TI SEM Team:
- Is the remote station also a DP83867?
--> No, but the exact manufacturer is not known
- Does the problem always occur, or what exactly does "Power Cycles the DP83867 module is supposedly disturbed / confused" mean?
--> The problem occurs sporadically during the power cycle of the remote station. Not during the power cycle of the DP83867
- What exactly happens during the power cycle in the event of an error? Is the power-up sequence adhered to? It may be possible to measure the power-up sequence with a scope.
--> Only the remote station is restarted or switched on again. Until then, everything seems to be OK with the DP83867, so I would rule out the power-up sequence for the time being.Before the power cycle problem, communication via MDIO/MDC is possible without any problems. Communication is only disrupted when the error occurs.
At this point, the PHY appears to respond to the request with data via MDIO/MDC. However, always with the same date, regardless of the address addressed.
- What does it mean that the DP83867 can still be reached, but the data is inconsistent?
--> The MDIO interface is working. However, the DP83867 always responds with the same date. Regardless of the address addressed. (However, this still needs to be verified by measurement on the target).
- SW Restart is to write the value 0x4000 to register 0x1F. Has this been tried?
Neither a SW restart via register 0x1F nor a reset to register 0x0 brings the PHY back to normal operation. Only a hardware reset via GPIO provides a remedy.
- Is it possible to reset the PHY via GPIO and does it work again afterwards?
--> This seems to work.
What Ethernet cable length is used in the test? Short cable, e.g. <1m? Perhaps try a different cable length, e.g. 20m, and see if the error pattern changes.
--Different cable lengths have no influence on the behavior.
Thanks
Jan
