• State Resolved
  • Locked Locked
  • Replies 27 replies
  • Answers 2 answers
  • Subscribers 34 subscribers
  • Views 2726 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DP83822I: PHY not stable, random operation behavior, latch in voltages do not match register values in 0x467, 0x468

Kevin Wood61
Prodigy 230 points
Part Number: DP83822I

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

  • 0
    Prodigy 230 points

    phy_reg_dump.txt 
     [D] ../main.c:379 - id 0x0000 -        3100    3100
 [D] ../main.c:379 - id 0x0001 -        7869    7849
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0002 -        2000    2000
 [D] ../main.c:379 - id 0x0003 -        a240    a240
 [D] ../main.c:379 - id 0x0004 -        01e1    01e1
 [D] ../main.c:379 - id 0x0005 -        41e1    0000
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0006 -        0007    0006
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0007 -        2001    2001
 [D] ../main.c:379 - id 0x0008 -        0000    0000
 [D] ../main.c:379 - id 0x0009 -        0000    0000
 [D] ../main.c:379 - id 0x000a -        0100    0100
 [D] ../main.c:379 - id 0x000b -        1000    1000
 [D] ../main.c:379 - id 0x000c -        0000    0000
 [D] ../main.c:379 - id 0x000d -        0000    0000
 [D] ../main.c:379 - id 0x000e -        0000    0000
 [D] ../main.c:379 - id 0x000f -        0000    0000
 [D] ../main.c:379 - id 0x0010 -        4815    4812
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0011 -        0108    0108
 [D] ../main.c:379 - id 0x0012 -        e400    e400
 [D] ../main.c:379 - id 0x0013 -        6800    2800
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0014 -        0000    0000
 [D] ../main.c:379 - id 0x0015 -        0000    0000
 [D] ../main.c:379 - id 0x0016 -        0100    0100
 [D] ../main.c:379 - id 0x0017 -        004d    004d
 [D] ../main.c:379 - id 0x0018 -        0400    0400
 [D] ../main.c:379 - id 0x0019 -        8c20    8021
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x001a -        0000    0000
 [D] ../main.c:379 - id 0x001b -        007d    007d
 [D] ../main.c:379 - id 0x001c -        05ee    05ee
 [D] ../main.c:379 - id 0x001d -        0000    0000
 [D] ../main.c:379 - id 0x001e -        0102    0102
 [D] ../main.c:379 - id 0x001f -        0000    0000
 [D] ../main.c:379 - id 0x0020 -        3100    3100
 [D] ../main.c:379 - id 0x0021 -        786d    7849
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0022 -        2000    2000
 [D] ../main.c:379 - id 0x0023 -        a240    a240
 [D] ../main.c:379 - id 0x0024 -        01e1    01e1
 [D] ../main.c:379 - id 0x0025 -        41e1    0000
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0026 -        0005    0004
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0027 -        2001    2001
 [D] ../main.c:379 - id 0x0028 -        0000    0000
 [D] ../main.c:379 - id 0x0029 -        0000    0000
 [D] ../main.c:379 - id 0x002a -        0100    0100
 [D] ../main.c:379 - id 0x002b -        1000    1000
 [D] ../main.c:379 - id 0x002c -        0000    0000
 [D] ../main.c:379 - id 0x002d -        0000    0000
 [D] ../main.c:379 - id 0x002e -        0000    0000
 [D] ../main.c:379 - id 0x002f -        0000    0000
 [D] ../main.c:379 - id 0x0030 -        4615    4002
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0031 -        0108    0108
 [D] ../main.c:379 - id 0x0032 -        0000    0000
 [D] ../main.c:379 - id 0x0033 -        0000    0000
 [D] ../main.c:379 - id 0x0034 -        0000    0000
 [D] ../main.c:379 - id 0x0035 -        0000    0000
 [D] ../main.c:379 - id 0x0036 -        0100    0100
 [D] ../main.c:379 - id 0x0037 -        0041    0041
 [D] ../main.c:379 - id 0x0038 -        0400    0400
 [D] ../main.c:379 - id 0x0039 -        8c20    8021
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x003a -        0000    0000
 [D] ../main.c:379 - id 0x003b -        007d    007d
 [D] ../main.c:379 - id 0x003c -        05ee    05ee
 [D] ../main.c:379 - id 0x003d -        0000    0000
 [D] ../main.c:379 - id 0x003e -        0102    0102
 [D] ../main.c:379 - id 0x003f -        0000    0000
 [D] ../main.c:379 - id 0x0040 -        3100    3100
 [D] ../main.c:379 - id 0x0041 -        786d    7849
 [D] ../main.c:381 - |different above|
 [D] ../main.c:379 - id 0x0042 -        2000    2000
 [D] ../main.c:391 - id 0x0467 -        2001    2001
 [D] ../main.c:391 - id 0x0468 -        0000    0000
 [D] ../main.c:391 - id 0x0469 -        0000    0000
 [D] ../main.c:400 - 0 reset
 [D] ../main.c:404 - 1 reset
 [D] ../main.c:415 - id 0x0000 -        3100    3100
 [D] ../main.c:415 - id 0x0001 -        786d    786d
 [D] ../main.c:415 - id 0x0002 -        2000    2000
 [D] ../main.c:415 - id 0x0003 -        a240    a240
 [D] ../main.c:415 - id 0x0004 -        01e1    01e1
 [D] ../main.c:415 - id 0x0005 -        41e1    4101
 [D] ../main.c:417 - |different above|
 [D] ../main.c:415 - id 0x0006 -        0007    0007
 [D] ../main.c:415 - id 0x0007 -        2001    2001
 [D] ../main.c:415 - id 0x0008 -        0000    0000
 [D] ../main.c:415 - id 0x0009 -        0000    0000
 [D] ../main.c:415 - id 0x000a -        0100    0100
 [D] ../main.c:415 - id 0x000b -        1000    1000
 [D] ../main.c:415 - id 0x000c -        0000    0000
 [D] ../main.c:415 - id 0x000d -        0000    0000
 [D] ../main.c:415 - id 0x000e -        0000    0000
 [D] ../main.c:415 - id 0x000f -        0000    0000
 [D] ../main.c:415 - id 0x0010 -        4215    4215
 [D] ../main.c:415 - id 0x0011 -        0108    0108
 [D] ../main.c:415 - id 0x0012 -        6400    6400
 [D] ../main.c:415 - id 0x0013 -        2800    2800
 [D] ../main.c:415 - id 0x0014 -        0000    0000
 [D] ../main.c:415 - id 0x0015 -        0000    0000
 [D] ../main.c:415 - id 0x0016 -        0100    0100
 [D] ../main.c:415 - id 0x0017 -        0041    0041
 [D] ../main.c:415 - id 0x0018 -        0400    0400
 [D] ../main.c:415 - id 0x0019 -        8c20    8c21
 [D] ../main.c:417 - |different above|
 [D] ../main.c:415 - id 0x001a -        0000    0000
 [D] ../main.c:415 - id 0x001b -        007d    007d
 [D] ../main.c:415 - id 0x001c -        05ee    05ee
 [D] ../main.c:415 - id 0x001d -        0000    0000
 [D] ../main.c:415 - id 0x001e -        0102    0102
 [D] ../main.c:415 - id 0x001f -        0000    0000
 [D] ../main.c:415 - id 0x0020 -        3100    3100
 [D] ../main.c:415 - id 0x0021 -        786d    786d
 [D] ../main.c:415 - id 0x0022 -        2000    2000
 [D] ../main.c:415 - id 0x0023 -        a240    a240
 [D] ../main.c:415 - id 0x0024 -        01e1    01e1
 [D] ../main.c:415 - id 0x0025 -        41e1    4101
 [D] ../main.c:417 - |different above|
 [D] ../main.c:415 - id 0x0026 -        0005    0005
 [D] ../main.c:415 - id 0x0027 -        2001    2001
 [D] ../main.c:415 - id 0x0028 -        0000    0000
 [D] ../main.c:415 - id 0x0029 -        0000    0000
 [D] ../main.c:415 - id 0x002a -        0100    0100
 [D] ../main.c:415 - id 0x002b -        1000    1000
 [D] ../main.c:415 - id 0x002c -        0000    0000
 [D] ../main.c:415 - id 0x002d -        0000    0000
 [D] ../main.c:415 - id 0x002e -        0000    0000
 [D] ../main.c:415 - id 0x002f -        0000    0000
 [D] ../main.c:415 - id 0x0030 -        4615    4615
 [D] ../main.c:415 - id 0x0031 -        0108    0108
 [D] ../main.c:415 - id 0x0032 -        0000    0000
 [D] ../main.c:415 - id 0x0033 -        0000    0000
 [D] ../main.c:415 - id 0x0034 -        0000    0000
 [D] ../main.c:415 - id 0x0035 -        0000    0000
 [D] ../main.c:415 - id 0x0036 -        0100    0100
 [D] ../main.c:415 - id 0x0037 -        0041    0041
 [D] ../main.c:415 - id 0x0038 -        0400    0400
 [D] ../main.c:415 - id 0x0039 -        8c20    8c21
 [D] ../main.c:417 - |different above|
 [D] ../main.c:415 - id 0x003a -        0000    0000
 [D] ../main.c:415 - id 0x003b -        007d    007d
 [D] ../main.c:415 - id 0x003c -        05ee    05ee
 [D] ../main.c:415 - id 0x003d -        0000    0000
 [D] ../main.c:415 - id 0x003e -        0102    0102
 [D] ../main.c:415 - id 0x003f -        0000    0000
 [D] ../main.c:415 - id 0x0040 -        3100    3100
 [D] ../main.c:415 - id 0x0041 -        786d    786d
 [D] ../main.c:415 - id 0x0042 -        2000    2000
 [D] ../main.c:427 - id 0x0467 -        2001    2001
 [D] ../main.c:427 - id 0x0468 -        0000    0000
 [D] ../main.c:427 - id 0x0469 -        0000    0000

  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    Data in TXT:
    Left Column is PHY0 and the Right Column is PHY1
    Second Data Set is after the Reset bit is toggled over the MDIO port.
  • 0 in reply to Kevin Wood61
    TI__Mastermind 23675 points
    Hi Kevin,

    Sorry to hear about the issues with your login. Have you contacted our TI Forum support group regarding this issue?

    About the DP83822I, the reason why you keep seeing the same value for register 0x467 and 0x468 is that you are doing a basic register read when you should instead implement an extended register read. It is confusing and sorry that you ran into this issue.
    Here is how you can read register 0x467:
    1. write to register 0xD value 0x1F
    2. write to register 0xE value 0x467
    3. write to register 0xD value 0x401F
    4. read register 0xE (the value in 0xE is 0x467 value); think of it like a pointer

    Can you do this for both 0x467 and 0x468? We can then see what mode the PHY is strapping to.
    Also, is there any way you can send us your schematic?
  • 0 in reply to Kevin Wood61
    TI__Mastermind 19780 points
    Hi Kevin,

    I think this is all explained by the fact that you're not performing reads/writes of the extended register space correctly. This is evidenced by looking at your reads of register above address 0x1f. If you ignore register address bits above bit[4], you can see the register values repeat. That is because the extra register address bits are being ignored.

    IE.
    [D] ../main.c:379 - id 0x0002 - 2000 2000
    [D] ../main.c:379 - id 0x0022 - 2000 2000
    [D] ../main.c:379 - id 0x0042 - 2000 2000

    and
    [D] ../main.c:379 - id 0x0007 - 2001 2001
    [D] ../main.c:379 - id 0x0027 - 2001 2001
    [D] ../main.c:391 - id 0x0467 - 2001 2001


    What all these register reads have in common is the register address bit[4:0] are the same and you get the same value. This is expected. In order to access the extended register space correctly, please perform the access method described in the datasheet: 8.4.2.5 Read (No Post Increment) Operation, and 8.4.2.6 Write (Post Increment) Operation

    Because so many issues and questions are conflated, can you take this knowledge and re-evaluate your system and get back to me with any questions you may have? This explanation answers questions 1 and 2 from your thread.

    For question 3, the PHY latches the straps at POR or during RESET of the device. The datasheet timing diagrams refer to this as latch-in. When latch-in occurs, the voltage is sampled at the pin. The strapped options are then loaded into the PHY and treated as default. The strapped values CAN be changed, with the exception of PHY address, during normal operation. If you reset the PHY using MDIO, then strap values will return to their initially sampled states. If you strobe the RESET pin, then the straps will be resampled entirely.

    4. & 5. Modes 2 and 3 for LED_0 are internally reserved modes for testing of the device. They will result in a non-functional device if you strap into them.

    6. & 7. Your register access method is incorrect. Please retest with the proper access method.

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 230 points

    Hi Rob,

    This is fantastic information.  We are going to review all this and re-evaluate the register information as you guys recommend.  I think that this makes sense and will give us the correct information we need to diagnose our problem correctly!  We will get back with good data shortly.

    Thank you guys for helping us through this issue!

    Kevin

  • 0 in reply to Ross Pimentel
    Prodigy 230 points
    Thanks Ross! The help is greatly appreciated. As mentioned below, we are working on fixing our read/write operations. Regarding the login issues with the email address, I did submit a request with the website feedback form.
  • 0 in reply to Kevin Wood61
    Prodigy 230 points

    PHY0 PHY1 new_dump.txt 
     [D] ../main.c:387 - id 0x0000 -   3100    3100
 [D] ../main.c:387 - id 0x0001 -        7849    7849
 [D] ../main.c:402 - REG1 LINK 0        0
 [D] ../main.c:387 - id 0x0002 -        2000    2000
 [D] ../main.c:387 - id 0x0003 -        a240    a240
 [D] ../main.c:387 - id 0x0004 -        01e1    01e1
 [D] ../main.c:387 - id 0x0005 -        0000    0000
 [D] ../main.c:387 - id 0x0006 -        0004    0004
 [D] ../main.c:387 - id 0x0007 -        2001    2001
 [D] ../main.c:387 - id 0x0008 -        0000    0000
 [D] ../main.c:387 - id 0x0009 -        0000    0000
 [D] ../main.c:387 - id 0x000a -        0100    0100
 [D] ../main.c:387 - id 0x000b -        1000    1000
 [D] ../main.c:387 - id 0x000c -        0000    0000
 [D] ../main.c:387 - id 0x000d -        401f    401f
 [D] ../main.c:387 - id 0x000e -        0000    0000
 [D] ../main.c:387 - id 0x000f -        0000    0000
 [D] ../main.c:387 - id 0x0010 -        0002    0315
 [D] ../main.c:397 - LINK 0     1
 [D] ../main.c:399 - MDIX 0     0
 [D] ../main.c:387 - id 0x0011 -        0108    0108
 [D] ../main.c:387 - id 0x0012 -        0000    6400
 [D] ../main.c:387 - id 0x0013 -        0800    2800
 [D] ../main.c:387 - id 0x0014 -        0000    0000
 [D] ../main.c:387 - id 0x0015 -        0000    0000
 [D] ../main.c:387 - id 0x0016 -        0100    0100
 [D] ../main.c:387 - id 0x0017 -        0041    0041
 [D] ../main.c:387 - id 0x0018 -        0400    0400
 [D] ../main.c:387 - id 0x0019 -        8020    8c21
 [D] ../main.c:393 - PHY MII LINK: 32   32
 [D] ../main.c:387 - id 0x001a -        0000    0000
 [D] ../main.c:387 - id 0x001b -        007d    007d
 [D] ../main.c:387 - id 0x001c -        05ee    05ee
 [D] ../main.c:387 - id 0x001d -        0000    0000
 [D] ../main.c:387 - id 0x001e -        0102    0102
 [D] ../main.c:387 - id 0x001f -        0000    0000
 [D] ../main.c:414 - id 0x0020 -        3100    5668
 [D] ../main.c:414 - id 0x0021 -        7849    5814
 [D] ../main.c:414 - id 0x0022 -        2000    0718
 [D] ../main.c:414 - id 0x0023 -        a240    081c
 [D] ../main.c:414 - id 0x0024 -        01e1    f01c
 [D] ../main.c:414 - id 0x0025 -        0000    0000
 [D] ../main.c:414 - id 0x0026 -        0004    0000
 [D] ../main.c:414 - id 0x0027 -        2001    0000
 [D] ../main.c:414 - id 0x0028 -        0000    0000
 [D] ../main.c:414 - id 0x0029 -        0000    0000
 [D] ../main.c:414 - id 0x002a -        0100    7998
 [D] ../main.c:414 - id 0x002b -        1000    f810
 [D] ../main.c:414 - id 0x002c -        0000    ff80
 [D] ../main.c:414 - id 0x002d -        401f    0100
 [D] ../main.c:414 - id 0x002e -        0000    0000
 [D] ../main.c:414 - id 0x002f -        0000    0000
 [D] ../main.c:414 - id 0x0030 -        4002    0000
 [D] ../main.c:414 - id 0x0031 -        0108    0000
 [D] ../main.c:414 - id 0x0032 -        0000    0000
 [D] ../main.c:414 - id 0x0033 -        0800    0000
 [D] ../main.c:414 - id 0x0034 -        0000    0000
 [D] ../main.c:414 - id 0x0035 -        0000    0000
 [D] ../main.c:414 - id 0x0036 -        0100    0000
 [D] ../main.c:414 - id 0x0037 -        0041    0000
 [D] ../main.c:414 - id 0x0038 -        0400    0000
 [D] ../main.c:414 - id 0x0039 -        8020    0000
 [D] ../main.c:414 - id 0x003a -        0000    0000
 [D] ../main.c:414 - id 0x003b -        007d    0000
 [D] ../main.c:414 - id 0x003c -        05ee    0000
 [D] ../main.c:414 - id 0x003d -        0000    0000
 [D] ../main.c:414 - id 0x003e -        0102    0000
 [D] ../main.c:414 - id 0x003f -        0000    b4ff
 [D] ../main.c:414 - id 0x0040 -        3100    c11d
 [D] ../main.c:414 - id 0x0041 -        7849    0000
 [D] ../main.c:414 - id 0x0042 -        2000    0000
 [D] ../main.c:428 - id 0x0467 -        0000    0000
 [D] ../main.c:428 - id 0x0468 -        0000    0000
 [D] ../main.c:428 - id 0x0469 -        0000    0000

  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    We got a new data dump from the phy, but unfortunately now we are getting all 0's in the strap registers 0x467 0x468. I am not sure that is correct.
    Also, to make sure I am understanding the data properly in 0x467 and 0x468, if I get a 00 for RXD0 for example in 0x467(13:12), does that correspond (in table 11) to the bits associated with those strap values AN_1=0, and PHY_AD1=0, which is actually mode 2, not mode 0? From what I read it is NOT the case where 00=mode 1, 01=mode2, 10=mode3, 11=mode4. The strap bit values and the mode numbers are completely independent from each other for all pins?
  • 0 in reply to Kevin Wood61
    TI__Mastermind 19780 points
    Kevin,

    It looks like you may still have an issue going on with your register access. At least PHY0 is still giving you what appears to be only the standard registers.

    [D] ../main.c:414 - id 0x0040 - 3100 c11d
    [D] ../main.c:414 - id 0x0041 - 7849 0000
    [D] ../main.c:414 - id 0x0042 - 2000 0000

    The tell-tale here is register 0x2 ALWAYS returns 0x2000.

    PHY1 looks like it is doing better, but is still reporting 0x0000 for 0x467 and 0x0000 for 0x468 even though you are strapping the PHY address properly. So I believe you are still seeing issues. As it stands, if your access to PHY1 is valid and you're using PHY address = 0x1, then at a minimum your value in 0x467 bit[11] = 1

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 230 points
    We will continue to review the firmware to make sure that gets sorted out. I will share this portion of the schematic with you guys via email tomorrow. We are also considering changing out one of the phy's soon with a fresh IC if there is a chance it is damaged.
  • 0 in reply to Kevin Wood61
    Prodigy 230 points

    PHY0 PHY1 dump 4-25 11am.txt 
     [D] ../main.c:387 - id 0x0000 -        3100    3100
 [D] ../main.c:387 - id 0x0001 -        7849    786d
 [D] ../main.c:387 - id 0x0002 -        2000    2000
 [D] ../main.c:387 - id 0x0003 -        a240    a240
 [D] ../main.c:387 - id 0x0004 -        01e1    01e1
 [D] ../main.c:387 - id 0x0005 -        0000    4101
 [D] ../main.c:387 - id 0x0006 -        0004    0007
 [D] ../main.c:387 - id 0x0007 -        2001    2001
 [D] ../main.c:387 - id 0x0008 -        0000    0000
 [D] ../main.c:387 - id 0x0009 -        0000    0000
 [D] ../main.c:387 - id 0x000a -        0100    0100
 [D] ../main.c:387 - id 0x000b -        1000    1000
 [D] ../main.c:387 - id 0x000c -        0000    0000
 [D] ../main.c:387 - id 0x000d -        0000    0000
 [D] ../main.c:387 - id 0x000e -        0000    0000
 [D] ../main.c:387 - id 0x000f -        0000    0000
 [D] ../main.c:387 - id 0x0010 -        0002    0215
 [D] ../main.c:387 - id 0x0011 -        0108    0108
 [D] ../main.c:387 - id 0x0012 -        0000    6400
 [D] ../main.c:387 - id 0x0013 -        0800    2800
 [D] ../main.c:387 - id 0x0014 -        0000    0000
 [D] ../main.c:387 - id 0x0015 -        0000    0000
 [D] ../main.c:387 - id 0x0016 -        0100    0100
 [D] ../main.c:387 - id 0x0017 -        0041    0041
 [D] ../main.c:387 - id 0x0018 -        0400    0400
 [D] ../main.c:387 - id 0x0019 -        8020    8c21
 [D] ../main.c:387 - id 0x001a -        0000    0000
 [D] ../main.c:387 - id 0x001b -        007d    007d
 [D] ../main.c:387 - id 0x001c -        05ee    05ee
 [D] ../main.c:387 - id 0x001d -        0000    0000
 [D] ../main.c:387 - id 0x001e -        0102    0102
 [D] ../main.c:387 - id 0x001f -        0000    0000
 [D] ../main.c:414 - id 0x0020 -        5668    5668
 [D] ../main.c:414 - id 0x0021 -        5814    5814
 [D] ../main.c:414 - id 0x0022 -        0718    0718
 [D] ../main.c:414 - id 0x0023 -        081c    081c
 [D] ../main.c:414 - id 0x0024 -        f01c    f01c
 [D] ../main.c:414 - id 0x0025 -        0200    0000
 [D] ../main.c:414 - id 0x0026 -        0000    0000
 [D] ../main.c:414 - id 0x0027 -        0000    0000
 [D] ../main.c:414 - id 0x0028 -        0000    0000
 [D] ../main.c:414 - id 0x0029 -        0000    0000
 [D] ../main.c:414 - id 0x002a -        7998    7998
 [D] ../main.c:414 - id 0x002b -        f810    f810
 [D] ../main.c:414 - id 0x002c -        ff80    ff80
 [D] ../main.c:414 - id 0x002d -        0800    0100
 [D] ../main.c:414 - id 0x002e -        0000    0000
 [D] ../main.c:414 - id 0x002f -        0000    0000
 [D] ../main.c:414 - id 0x0030 -        0000    0000
 [D] ../main.c:414 - id 0x0031 -        0000    0000
 [D] ../main.c:414 - id 0x0032 -        0000    0000
 [D] ../main.c:414 - id 0x0033 -        0000    0000
 [D] ../main.c:414 - id 0x0034 -        0000    0000
 [D] ../main.c:414 - id 0x0035 -        0000    0000
 [D] ../main.c:414 - id 0x0036 -        0000    0000
 [D] ../main.c:414 - id 0x0037 -        0000    0000
 [D] ../main.c:414 - id 0x0038 -        0000    0000
 [D] ../main.c:414 - id 0x0039 -        0000    0000
 [D] ../main.c:414 - id 0x003a -        0000    0000
 [D] ../main.c:414 - id 0x003b -        0000    0000
 [D] ../main.c:414 - id 0x003c -        0000    0000
 [D] ../main.c:414 - id 0x003d -        0000    0000
 [D] ../main.c:414 - id 0x003e -        0000    0000
 [D] ../main.c:414 - id 0x003f -        b4ff    b4ff
 [D] ../main.c:414 - id 0x0040 -        c11d    c11d
 [D] ../main.c:414 - id 0x0041 -        0000    0000
 [D] ../main.c:414 - id 0x0042 -        0000    0000
 [D] ../main.c:428 - id 0x0467 -        0000    0000
 [D] ../main.c:428 - id 0x0468 -        0000    0000
 [D] ../main.c:428 - id 0x0469 -        0000    0000

  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    We did find another bug where a section wasn't updated with the new read. Here is our latest data dump. We are still getting all zeros in 467 468.
  • 0 in reply to Kevin Wood61
    TI__Mastermind 19780 points
    Hi Kevin,

    There are some obviously conflicting information in your register dumps that are perplexing. For example, the LED_0 polarity is set to active low. This is to be expected as active low LED polarity means you have strapped the LED pin in mode 4. As I see from your measured stap voltages, mode 4 is what you are targeting.

    Yet register 0x467 says your LED_0 strap is in mode 1 which is not correct. This should be happening on the PHY.

    Can you do me a favor and do a line by line read of register 0x467?

    Perform the read manually if possible with the 4 access method.

    0xd = 0x001f
    0xe = 0x0462
    0xd = 0x401f //no post-increment option!
    read 0xe

    If this doesn't work, then there is something very wrong with the initialization of the PHY or some other factor.

    It may be helpful if you could share the schematic as well. I know you said you were limited in what you could share, but besides just guessing at some things from this point on, I can only give you generic guidance.

    Like float connections to your MAC. Remove any ferrite beads and replace with 0 ohm resistors, measure reference clock. Ensure power up timing is valid.

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 230 points

    Thanks for the feedback Rob.  I think we found another bug in the dump code.  We are going to give it another go and see what we find.  I sent copies of the phy and XMC schematic sections to Ruben Perez and Andrey Volynets (the engineers assigned to our company).

  • 0 in reply to Kevin Wood61
    Prodigy 230 points

    pelvis_new_dump 4-26-2018.txt 
      [D] ../main.c:395 - id 0x0000 -   3100    3100
 [D] ../main.c:395 - id 0x0001 -        7849    786d
 [D] ../main.c:395 - id 0x0002 -        2000    2000
 [D] ../main.c:395 - id 0x0003 -        a240    a240
 [D] ../main.c:395 - id 0x0004 -        01e1    01e1
 [D] ../main.c:395 - id 0x0005 -        0000    4101
 [D] ../main.c:395 - id 0x0006 -        0004    0007
 [D] ../main.c:395 - id 0x0007 -        2001    2001
 [D] ../main.c:395 - id 0x0008 -        0000    0000
 [D] ../main.c:395 - id 0x0009 -        0000    0000
 [D] ../main.c:395 - id 0x000a -        0100    0100
 [D] ../main.c:395 - id 0x000b -        1000    1000
 [D] ../main.c:395 - id 0x000c -        0000    0000
 [D] ../main.c:395 - id 0x000d -        401f    401f
 [D] ../main.c:395 - id 0x000e -        0040    0001
 [D] ../main.c:395 - id 0x000f -        0000    0000
 [D] ../main.c:395 - id 0x0010 -        0002    0215
 [D] ../main.c:395 - id 0x0011 -        0108    0108
 [D] ../main.c:395 - id 0x0012 -        0000    6400
 [D] ../main.c:395 - id 0x0013 -        0800    2800
 [D] ../main.c:395 - id 0x0014 -        0000    0000
 [D] ../main.c:395 - id 0x0015 -        0000    0000
 [D] ../main.c:395 - id 0x0016 -        0100    0100
 [D] ../main.c:395 - id 0x0017 -        0041    0041
 [D] ../main.c:395 - id 0x0018 -        0400    0400
 [D] ../main.c:395 - id 0x0019 -        8020    8c21
 [D] ../main.c:395 - id 0x001a -        0000    0000
 [D] ../main.c:395 - id 0x001b -        007d    007d
 [D] ../main.c:395 - id 0x001c -        05ee    05ee
 [D] ../main.c:395 - id 0x001d -        0000    0000
 [D] ../main.c:395 - id 0x001e -        0102    0102
 [D] ../main.c:395 - id 0x001f -        0000    0000
 [D] ../main.c:422 - id 0x0020 -        5668    5668
 [D] ../main.c:422 - id 0x0021 -        5814    5814
 [D] ../main.c:422 - id 0x0022 -        0718    0718
 [D] ../main.c:422 - id 0x0023 -        081c    081c
 [D] ../main.c:422 - id 0x0024 -        f01c    f01c
 [D] ../main.c:422 - id 0x0025 -        0200    0000
 [D] ../main.c:422 - id 0x0026 -        0000    0000
 [D] ../main.c:422 - id 0x0027 -        0000    0000
 [D] ../main.c:422 - id 0x0028 -        0000    0000
 [D] ../main.c:422 - id 0x0029 -        0000    0000
 [D] ../main.c:422 - id 0x002a -        7998    7998
 [D] ../main.c:422 - id 0x002b -        f810    f810
 [D] ../main.c:422 - id 0x002c -        ff80    ff80
 [D] ../main.c:422 - id 0x002d -        0800    0100
 [D] ../main.c:422 - id 0x002e -        0000    0000
 [D] ../main.c:422 - id 0x002f -        0000    0000
 [D] ../main.c:422 - id 0x0030 -        0000    0000
 [D] ../main.c:422 - id 0x0031 -        0000    0000
 [D] ../main.c:422 - id 0x0032 -        0000    0000
 [D] ../main.c:422 - id 0x0033 -        0000    0000
 [D] ../main.c:422 - id 0x0034 -        0000    0000
 [D] ../main.c:422 - id 0x0035 -        0000    0000
 [D] ../main.c:422 - id 0x0036 -        0000    0000
 [D] ../main.c:422 - id 0x0037 -        0000    0000
 [D] ../main.c:422 - id 0x0038 -        0000    0000
 [D] ../main.c:422 - id 0x0039 -        0000    0000
 [D] ../main.c:422 - id 0x003a -        0000    0000
 [D] ../main.c:422 - id 0x003b -        0000    0000
 [D] ../main.c:422 - id 0x003c -        0000    0000
 [D] ../main.c:422 - id 0x003d -        0000    0000
 [D] ../main.c:422 - id 0x003e -        0000    0000
 [D] ../main.c:422 - id 0x003f -        b4ff    b4ff
 [D] ../main.c:422 - id 0x0040 -        c11d    c11d
 [D] ../main.c:422 - id 0x0041 -        0000    0000
 [D] ../main.c:422 - id 0x0042 -        0000    0000
 [D] ../main.c:436 - id 0x0460 -        0551    0551
 [D] ../main.c:436 - id 0x0461 -        0410    0410
 [D] ../main.c:436 - id 0x0462 -        0001    0001
 [D] ../main.c:436 - id 0x0463 -        0000    0000
 [D] ../main.c:436 - id 0x0464 -        0000    0000
 [D] ../main.c:436 - id 0x0465 -        ff00    ff00
 [D] ../main.c:436 - id 0x0466 -        ff00    ff00
 [D] ../main.c:436 - id 0x0467 -        038f    0f8f
 [D] ../main.c:436 - id 0x0468 -        0000    0000
 [D] ../main.c:436 - id 0x0469 -        0040    0040

  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    We believe we are now reading the data out of the extended registers properly. Here is a dump of what we are getting. I am posting more information shortly.
  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    The pdf shows the strap in modes circled in BLACK as read in by the 0x467 and 0x468. The strap modes circled in RED are desired strap modes. The right columns in Black display the following: the actual measured strap voltages as seen on the scope, and the actual hardware strap configuration on the chip's pins. Comparing the RED and the BLACK desired/actual information, I can see that the measured strap in voltages match the desired strap in configurations that we are looking for, but many pins on the chip are coming up in totally different strap modes from what they should be.

    I believe this identifies the discrepancy between desired operation and actual operation, but does not explain how the chip came to be this way.

    We are also considering the possibility that the chip is damaged. We have investigated the power supply and think that it is possible that could be an overvoltage incident happening at power up, but aren't 100% sure about this because the transient on the scope is really fast, and could be related to inductance in ground probe cabling. Additionally, many other devices such as XMC processor, 2x LAN9252's, EEPROMS are all working normally. If there was an overvoltage issue, I would expect other devices to be failing as well, which makes me somewhat skeptical of this theory.

    At this point I would like to try replacing two PHY's and see if that can fix the problem. We are going to strobe the GPIO pins that connect to the phy after we pull the chips off to validate trace connections to the BGA. When we replace them we will use an external 3.3V supply . If it was a power supply overvoltage incident, then I can duplicate the problem by reconnecting the onboard supply after I replace them. If I replace them and they are still bad, they are either getting damaged somehow or arrived bad in the first place.

    If you guys have any other thoughts or explanations about what could be the issue causing this that would be great.

    Thanks, Kevin.
  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    I re-evaluated how I was translating the data from 0x467 and 0x468. The first time I was using the data in 467 and 468 to populate the strap function bits in table 11. This time I associated the bits in 467 and 468 with the mode numbers instead. This seemed to line up to what I wanted exactly. However, this still doesn't explain why the chips aren't working. I am still considering the possibility that they were damaged.
  • 0 in reply to Kevin Wood61
    Prodigy 230 points

    After re-evaluating our code, we are getting good data out of the mdio.  Once we fixed the way we associated 467 and 468 to mode values, we found only one mistake in strapping.  We fixed that and are getting correct strap values now.  We now have constant link and 100mbps on both phys.  Despite that, We are still having intermittent performance with ethercat datagrams.  Sometimes we get all 8 slaves, sometimes none.  If we bypass the phys/xmc it runs continuously without issues.  It is difficult to pinpoint what the issue is since it works for short periods of time, and usually needs a power cycle to work again.

  • 0 in reply to Kevin Wood61
    TI__Mastermind 19780 points
    Hi Kevin,

    I am glad to hear you are making progress with strapping the PHY and reading registers.

    Can you describe what you mean by the Ethercat datagrams are having issues? Are you receiving frames that are errored and being discarded? Are you not receiving Ethernet frames at all?

    What is providing your reference clock to the PHYs? With a lot of Ethercat controllers, the reference clock is provided by the controller to the PHY. Is there high jitter on this reference?

    Does the IPG between the datagrams make any difference in reliability of the link?

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 230 points
    The xmc supplies the 25mhz reference clock to the phys, and runs at 25mhz on the scope when probing the pins on the phy. I was seeing variation of +/- 150ps in pulse width on the scope. As for the datagram issues I will have to have our firmware engineer chime in on that. I also dont know the answer to the interpacket gap question. I will have to find measure that.
  • 0 in reply to Kevin Wood61
    Prodigy 230 points

    While the firmware engineer investigates the issues mentioned above, we also are going to perform some loopback tests.  Since the PHY is able to always maintain link, it seems like if there is a hardware issue that it is on the MII side.  By running an MII loopback in the PHY back to the XMC we can try to validate those connections.

    For the test patterns, does the test pattern come out of the MII port of the MDI physical medium?  We are considering running that test but did not see much info in the datasheet on where it is broadcast to.

    We are also going to try to drive an external phy on an eval board with a couple low level nibbles and push that into the phy's having issues and see if we can read that into the XMC.

  • 0 in reply to Kevin Wood61
    Prodigy 230 points
    Rob, Did you by chance get a copy of the schematic sections from Ruben Perez to look at?
  • 0 in reply to Kevin Wood61
    TI__Mastermind 19780 points
    Ultimately there were 2 things that needed to be solved for this system to come up: extended register space access had to be corrected, and a register setting for class A operation of the DP83822 was needed.

    For further information, when using capacitive coupling and the DP83822, register 0x404 must be set to value 0x0024 for reliable communication.

    Best Regards,
  • 0 in reply to Kevin Wood61
    Prodigy 230 points

    Rob suggested in an email switching register 0x0404 to 0x0024 inside the phy's. This switched the driver stages on the MDI interface to class A instead of AB which was necessary for capacitive coupling that was on our design. This made the phy's work and brought the whole ethercat chain to life! Thanks to Rob and everyone that helped on this problem. This seems like the largest contributor to our problems as to why the phy's weren't doing much at all. The strap registers were definitely important in getting sorted out as well though.