Hello,
First off, I would like to say that I am a contractor working for a specific company, but I was not able to use my email address associated with that company on the E2E web site. I have tried logging in multiple times on 2 different browsers and on 2 different machines to verify the problem. I was able to narrow it down to the fact that the E2E web site will not accept my email address associated with that company, so I am using a personal TI profile to be able to post this question. This makes the E2E community totally inaccessible to someone with an email address that is similar to the one that was assigned to me. It was very frustrating trying to figure out a way to even post a question. I have not had this problem before with E2E. This problem also restricts how much information I can share to assist with troubleshooting my issue listed below.
Getting back to the DP83822I Issues:
I am working on a project with an XMC4800 processor and two DP83822I PHY's for ethercat, and I am the hardware engineer. We previously used a different PHY chip KSZ8081 which never had any issues. We were migrating to the DP83822I due to space contraints. We have had a lot of issues trying to get them to work. I have changed and fixed several mistakes in the design and have finally gotten it working, but it only works occassionally (1/10 times) and when it does, the ethercat operation doesn't seem to stay. The XMC4800 is the 4th slave from the upstream port on a design with 8 ethercat slaves. Some of the issues that I had fixed were the following:
A. I had RXD1 and RXD2 swapped going to the processor on one of the phys (fixed)
B. The LINK input on the processor MII was connected to LED1, and I moved it to LED0
C. Removed 2 solder bridges on one of the phy's because of excess solder (Pin1 shorted to ground body pad and pin 17 shorted to pin 18)
D. I have changed many of the strap pin configurations many times and not seen consistent performance in communication or in MDIO register states.
I recently read the new version of the datasheet (April 2018) and it explained that there are bootstrap modes controlled by the LED pin strap voltages of the datasheet. My current thought is that I am having some sort of a bootstrapping issue where the chip is not even operating under normal circumstances. Since there is no information in the datasheet about this I have no way to validate if this is what is happening other than checking the registers in 0x0467 and 0x0468. It does specify the register location LED0 but not LED1 in 0x0467 and 0x468. One of the key problems that I have reached an empass with is that the strap voltages at power up are not corresponding with the modes expressed by the bits in these registers when we do a PHY data dump over the MDIO port. We also do a reset to the phy's over the MDIO port and dump data both before and after the reset but get the same results for 0x467 and 0x468. I will list below specifically what we are getting.
Latch in Voltages:
LED0 = 3.3V
LED1 = 2.7V
RXD0=0V
RXD1=0V
RXD2=0V
RXD3=3.3V
RXER=3.3V
RXDV=0V
COL=0.12V
CRS=0.89V
0x467= 2001
0x468=0000
As far as I know, all the links are operating correctly on the physical layer (MDI) and on the MII bus. I have checked on the scope all the clocks and data lines and they look ok going to the PHY's, as well as from the PHY's to the XMC.
Additionally, as an example of this problem of random operation states, the address bits 4:0 of 0x0019 are correct for PHY0 and PHY1 (0,1 respectively), but the values for 0x467 for both phy's in the data dump are exactly the same, before and after the reset. COL pin on PHY1 is floating and COL pin on PHY0 has a 1.96K pull down resistor. I believe this is correct strapping for configuring address bits to 0,1, but it is not reflected in the latch in registers. There are other several registers in 0x467 and 0x468 that are not reflecting their latch-in values when you continue through the list above (RXD0, LED0, etc...).
1. Why would the latch-in voltages not match the modes associated with the values read in at 0x467 and 0x468 as specified by the datasheet?
2. Why would the address bits be correct when the latch in values are not?
3. How can I tell if the chip is in bootstrap?
4. What are the modes for LED1 that are associated with bootstrap (not listed in datasheet)?
5. Are modes 2 and 3 for LED0 associated with bootstrap (vaguely referenced in datasheet)?
6. Why is LED0 latching in at 3.3V and coming up as 01 in 0x0467 (mode 2)?
7. Why are these problems on both PHY chips?
I have been battling this problem for about 2 weeks. Some assistance would be very helpful! Thank you.
-Kevin