Part Number: DP83867IS
we have a customised board featuring the AM6548 and have in total seven DP83867 PHYs on this board. One for the MCU CPSW and two for each PRUSS instance. The connection and strapping for the PHYs is roughly equal - differences are in PHY address and the MCU CPSW has a 25 MHz quartz on XI/XO, while the PRUSS PHYs get a 25 MHz oscillator input on XI.
The MCU CPSW interface works perfectly in our Linux 5.4 using delays only on RX (phy-mode = "rgmii-rxid").
The PRUSS Ethernet interfaces don't work (same delay settings):
* Connected to a Gigabit Switch (TP-Link TL-SG1005D): Link LED goes on and off, no Link up reported to Linux. Workaround: Force Gigabit Master mode via register CFG1 bits 12,11.
* Any incoming data is recorded as RXerr bytes in the PHY.
Are there any debugging registers or any ideas why the PHY rejects received packets?
As you have mentioned slight strapping differences, you may check registers 0x6E and 0x6F of both the working and non-working setups to ensure both are strapped as expected. I would expect these values to be the same, as the only change you have mentioned was PHY address.
Additionally, can you provide a register dump for both the working and non-working PHY's for registers 0x0 - 0x1F, and 0x32.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Nikhil Menon:
the registers 0x6E and 0x6F were indeed equal.
Please find attached the requested register dumps.
I took one non-working PHY as an example against the one working.
I already marked the differences in the dump for better readability.
Interestingly the non-working phy on eth5 reports that it did not receive even the Link Code Word (register 0x06).
Because of the difference in register 0x11 suggesting different MDI/X settings, I already tried to force Manual MDI and MDI-X via register 0x10 bits 6:5 on eth5, but it not change the result.
In reply to Michael Krummsdorf:
A couple follow up questions:
1. What is the desired MAC interface?
2. What is the cable length used in both the working and non-working case?
3. On the connected pins between the PHY and processor, particularly the strap pins, are there differences in the internal pull values of the MCU CPSW versus the PRUSS module?
4. In the non-working case, Register 0x9 = 0x1A00, which is not the default value. Have any write statements been done to set this value? Does returning this register to value 0x0300 return the PHY to an operational state?
1) All PHYs are connected as RGMII.
2) I use the same cable - 1m length - when testing the working/non-working PHYs.
3) The pull settings are the same across all ethernet pins.
4) Yes, I needed to write that register to 0x1A00 on every PRU PHY in order to establish a link at all (CFG1, bit12,11 - see first post).
It should be mentioned, that we are using a AM6548 SR2.0 and these firmware files from 07.02.00.001:
I wanted to compare against the TI starterkit TMDX654GPEVM with the same DP83867 PHY and an AM6548 SR1.0 and using these firmware files:
PRG2 ethernet works on that board.
Some follow ups to the specific line items:
2. Is the issue also seen at other cable lengths, such as 10m or 20m?
4. Thanks for the clarification, I understand this operation now.
I only have a 10m cable available. Auto-negotiation does take a bit longer with it but in the end it's the same: Got Link up, but packets dropped.
Can we try both a near-end and far-end loopback test to help determine the source of the error? Please review section 8.4.4 in the datasheet for information on loopback modes. Let's try both an analog loopback and reverse loopback. Please let me know if errors are observed with either loopback experiment. Please let me know if you require additional information for setting up loopback modes.
I guess I need a little help in setting up and testing the two loopback modes.
Reverse Loopback test:
1. Set register 0x16 (BISCR) to 0x0020 (set bit 5)
Now I my PC I use wireshark to monitor packets on the Ethernet interface and send a ping to the device's IP address. But wireshark does only show the ARPs to ask who has that IP address.
Is that how you test this loopback mode?
Analog Loopback test:
1. Disable auto-negotiation: Set register 0x00 (BMCR) to 0x0140 (clear bit 12).
2. Disable Auto MDI/X, force manual MDI: Set register 0x10 (PHYCR) to 0x5008 (bits 6:5 to 0x00)
3. Set register 0x00FE (LOOPCR) to 0xE720.
4. Issue a sw restart: Set register 0x1F (CTRL), bit 14.
How do I test this loopback mode?
Then I assign an IP address to the ethernet interface and try to ping my host PC.
I have tcpdump on the target but I don't how to use it
Some additional notes for each test:
1. Reverse loopback: Writing 0x0016 = 0x0020 is the correct register setting. This should be all that is needed for this test. Do you have access to the MII pins of the PHY? If so, can you confirm you can observe MII data on these pins before setting the loopback mode? Have the link partner send the PHY data during normal operation and observe the RX_Data pins.
2. Analog loopback: You have the correct steps 1-3. Step 4 should be set analog loopback (register 0x16 = 0x0008). Then step 5 would be issue a soft reset (0x1F = 0x4000). For this test the PHY must be connected to a MAC, and the MAC should be set to generate packets, the PHY will loop the packets back to the MAC and the MAC should count the packets and display that there are no errors. The MDI pairs (cable side) should be terminated with a 100 ohm differential impedance. If the termination is not available, digital loopback can be used instead (set register 0x16 = 0x0004). However, analog loopback engages all analog blocks of the PHY and will be useful in fully confirming the functionality of the MDI side of the PHY.
Please let me know if this has helped clarify the setup for near-end loopback.
I will connect a scope to the RGMII pins and try to observe RX Data as you described.Will get back to you next week!
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.