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.

AMIC110: Ethernet port debugging

Part Number: AMIC110
Other Parts Discussed in Thread: TLK106, , TLK105

Hi all.  I have a custom board modeled after the TMDX110 ICE board that I am using for an EtherCAT application, except that I used TLK106 parts for the PHYs, since the DP83822s are unavailable. 

I have discovered that my PHY2 port (the one that is connected to J7 on the ICE board, and is supposed to be the upstream port) isn't working.  PHY1 seems to work fine, and my system works with that port, although since it is the downstream port, it throws an EtherCAT warning.  The PHY2 that isn't working does show a link light when I plug it in.  But it doesn't talk to the master.

I've checked my schematics against the AMIC110 ICE EVM Rev 1.1 schematics for the PHY connections to the micro, and with the exception of the TLK106 modifications, it all matches up, except I have the MDIO address on PHY2 set to 5 instead of 13 as is on the ICE. The software on the AMIC110 talks to the PHY OK once I changed the address to 5 from 13.  Could that be a problem for the PRU firmware?

I noticed that there are separate drivers/setup software for the TLK parts in the board support code base.  I thought maybe I needed to play with that, but since PHY1 works, I thought it wasn't a problem.  Could it be a PHY setup problem or a strap problem?

I'm wondering how to go about debugging this.  I saw from another e2e post that the Ethercat PRU firmware source isn't available, so I guess I'm reduced to probing the AMIC110 code.  I have some spare GPIO pins I could use to output to a logic analyser or scope.

John

  • Hello John, 

    Thank you for the query.

    I understand this is a custome board. Did you always use TLK or you initially used the DP83826 and transitioned to TLK.

    I will need additional information to resolve if this is an hardware issue or a software related issue.

    I'm wondering how to go about debugging this.  I saw from another e2e post that the Ethercat PRU firmware source isn't available, so I guess I'm reduced to probing the AMIC110 code.  I have some spare GPIO pins I could use to output to a logic analyser or scope.

    Do you have the ICE board to test the ethernet interface?

    Regards,

    Sreenivasa

  • Hi.  I have always had the TLK parts on there.  It's a good idea to try the ICE board with my code.  I think it should work.   I'll do that in the morning.

  • Hello John, 

    Thank you for the note.

    Please let me know how the testing progresses.

    https://www.ti.com/product/TLK106

    Is this a new design or an update to an older design. If i understand this is a new design that has been started with the TLK106.

    The reason is ask in the TLK106 in an NRND and not sure if this is something you have been aware.

    Regards,

    Sreenivasa

  • Yes, I know that it is NRND, but its replacement is not available, or at least it isn't until maybe June 2023 if I'm lucky enough to get a few.  The board was designed during the pandemic at the peak of the parts shortage.  The only place I could get the DP83822 was from unauthorized sources at 20x the list price!  I designed the hardware to be compatible with the DP83822x parts, which is what I want to use long-term. 

    The one setting on the TLK parts that seems to be different (referencing the DP83822 Hardware Rollover document (SNLA262) is the strap on pin 24, which does nothing on the TLK106, but sets the polarity of the LED1 on the DP83822.

    I figured out that the board is advertising only half-duplex modes for auto-negotiation, so this is a clue that the configuration of the PHY is not right.  I've attached my schematic of the PHYs.  If you would be so kind as to scan it for errors, I would appreciate it.  Aside from the extra parts for the TLK106, it should be the same as on the ICE rev1.1 schematic.

    John

    phy1and2.pdf

  • Hello John, 

    Thank you for the inputs.

    Can you start a new thread with title TLK106 schematics review for the PHY team to support review of the schematics. I am not a PHY expert and can only provide some guidance. 

    Regarding the pin strapping are you seeing the other PHY get configured as expected.

    The MDIO may need s pullup near to each PHY.

    Please check if the PHY has internal series reduce and reduce the 49.9R value.

    Do you have the series resistors for the TX signals near to the processor.

    Can you make sure the reset for the PHY is released after the power supplies are fully ramped.

    Regards,

    Sreenivasa

  • Yes, I will do so.  THe other PHY is also advertising itself as half duplex, so both are wrong.  But the other one seems to work.  I will check what you ask. 

    There is one 2.2k pull-up near the processor for the mdio line. 

    The TLK PHY does not have internal series resistance.  The newer DP83822x does have the built-in series resistors. 

    No, unfortunately the tx series resistors were placed near the PHY.  Our next rev will fix that, but the phy is only about 1" from the processor, so I think it ought to work.  But I'll keep that in mind.

    Thanks!

    John

  • Hello John, 

    Thank you.

    Let me know your findings after testing the PHY.

    If you are able to read the registers over MDIO, maybe you could try reading some of the PHY registers to understand the configuration.

    Regards,

    Sreenivasa

  • Thanks.  I'm writing a bit of code to dump all the phy registers now.

    John

  • Hello John, 

    Thank you for the note.

    There may be some internal self-tests that could be done.

    Please explore those options also.

    Regards,

    Sreenivasa

  • Hi.  I wrote some code to dump the PHY registers.  They all seem like reasonable values.  It turns out that the Ethernet side of the PHY seems to be working fine, and the autonegotiation locks up fine at 100mb/s full duplex.  I also found that my software runs fine on the TMDX110 eval board.  So the hardware is at fault.  I found a major flaw in my design, so hopefully once I replace the PHYs it will work.  I had the internal power supply of the TLK105 chips tied to 3.3V instead of letting the internal regulator power them.  So likely the TLK105s are damaged.  I have ordered a few new TLK105  to replace the probably fried ones.  We shall see.  Here's what I did that is obviously wrong.  I'll leave out the R160 when I get new PHY chips.

    John

  • Hello John, 

    Thank you for the inputs and good to hear you have been able to root cause.

    The way the circuit has been implemented, it would take some analysis to find the issue.

    DP83822 has these pins N/C. Not sure if they can remain shorted.

    We had done a design sometime back where we had provision to isolate the pins

    https://www.ti.com/cn/lit/ug/tidu274/tidu274.pdf

    Let me know if you have any additional question or we could close the thread. 

    Regards,

    Sreenivasa

  • Hi Sreeivasa.  I'm getting close!  I replaced the TLK105 chips and verified that their internal regulator is now providing 1.5 volts.

    I stepped through the init code to verify the setup.  I found that the LED_CFG register (MDIO register 19 bit 5) was misconfigured.  I edited the initialization code to fix that and have the LED on all the time instead of blinking with the activity.  Now, if I disable the enhanced link enable


    mdioParamsInit.enhancedlink_enable = TIESC_MDIO_RX_LINK_DISABLE;   (Line 1649 in tiescbsp.c)

    Then it all works!  No errors of any kind on either PHY link.

    But, I need to figure out why it does not work with the enhanced link detection, as my application requires it for cable redundancy.  I found a very useful document online,   SPRACC8A : Ethernet PHY Configuration Using MDIO for Industrial Applications

    This document is what I needed!  It shows how to use the debugger to look at the internal registers of the PRU, which is very helpful!  I am attaching a dump of the PHY registers of the PHY that is connected and running, but without enhanced link detection enabled.

    It seems that I am missing some configuration parameter (in the PRU?)  to make the system work with the TLK105 PHY's LINK LED .  Any ideas would be appreciated!

    John

    Phy:13, Register 0: Value:3000
    Phy:13, Register 1: Value:786d
    Phy:13, Register 2: Value:2000
    Phy:13, Register 3: Value:a211
    Phy:13, Register 4: Value:1e1
    Phy:13, Register 5: Value:81
    Phy:13, Register 6: Value:4
    Phy:13, Register 7: Value:2001
    Phy:13, Register 8: Value:0
    Phy:13, Register 9: Value:7400
    Phy:13, Register a: Value:126
    Phy:13, Register b: Value:9
    Phy:13, Register c: Value:0
    Phy:13, Register d: Value:0
    Phy:13, Register e: Value:0
    Phy:13, Register f: Value:0
    Phy:13, Register 10: Value:4611
    Phy:13, Register 11: Value:108
    Phy:13, Register 12: Value:0
    Phy:13, Register 13: Value:0
    Phy:13, Register 14: Value:0
    Phy:13, Register 15: Value:0
    Phy:13, Register 16: Value:100
    Phy:13, Register 17: Value:8
    Phy:13, Register 18: Value:480
    Phy:13, Register 19: Value:802d
    Phy:13, Register 1a: Value:0
    Phy:13, Register 1b: Value:7d
    Phy:13, Register 1c: Value:5ee
    Phy:13, Register 1d: Value:0
    Phy:13, Register 1e: Value:102
    Phy:13, Register 1f: Value:0

  • Hello Johan, 

    Thank you for the inputs.

    Based on your inputs, hardware seems to be working,

    Here are my thoughts to resolve the other issues.

    I am attaching a dump of the PHY registers of the PHY that is connected and running, but without enhanced link detection enabled.

    Please check the E2E threads or initiate a thread titles TLK105 - enhanced link detection. 

    The PHY team can provide inputs on any care abouts related to the TLK105. I assume the DP83822 has similar configurations. You could check the same for the DP83822.

    In parallel please initiate another thread titled configuring the AMIC110 PRU for enhanced link detection using TLK105

    The threads could be assigned to the relevant expert to provide the inputs.

    Have you looked for ethercat related information that could help.

    Example below

    e2e.ti.com/.../tmdsice3359-ethercat-operation

    Regards,

    Sreenivasa

  • Hello Sreenivasa.

    I finally figured out what was causing the enhanced link detection not to work.  The AMIC110 PRU enhanced link detection is wired to LED1 of the phy.  TLK105/TLK106 only has LED0, and pin 24, which is LED1 on the DP83822, is a power supply pin on the TLK.  So my LED was not connected to the processor pin that was looking for it.  A simple jumper wire from LED0 on the TLK to the PHYx_LED1 pin fixed it. 

    So in summary:

    You can't use the TLK without changing some software to properly configure the LEDs.

    Make sure that LED0 is connected to the PHYx_LED1 pin on the processor so the PRU can see it!

    Thanks for all your help and suggestions!

    John

  • Hello Johan, 

    Thank you for adding the notes that could be used by the wider E2E community.

    Have a good day.

    Regards,

    Sreenivasa