TLK105: issue of receiving data

Expert 1240 points

Di Wang1

Part Number: TLK105

Hi,

My TLK105 is designed to receive data only. I found sometimes after power up, MAC interface didn't output data. I checked by oscilloscope, there was signal on 100Mbs PMD Interface, but no signal was on MAC interface.

When I used this board to transmit data only, the communication was always fine.

I didn't configure the register, so TLK105 is in default mode. I have checked the hardware configuration, no problem is found.

Could recommend steps to locate and solve this issue? Or, which register I can have a try?

Thanks. 

Expert 1240 points

Di Wang1

• May 12, 2017 10:57 AM
• Locked
• Cancel

9 Replies

• Genius 13850 points

  

  Rob Rodrigues

  

  • May 12, 2017 6:14 PM

  Hi Di Wang,
  
  Can you provide a dump of all the registers in your TLK105 so I can see what might be happening? Please post all the registers in the datasheet.
  
  Best Regards,

  Rob Rodrigues

  EFL (Ethernet & FPD Link) Applications Engineer

  • Locked
  • Cancel
• Expert 1240 points

  

  Di Wang1

  

  • May 15, 2017 3:08 PM

  In reply to Rob Rodrigues:

  Hi Rob,
  Currently, my configuration can only read one bit once, so it is a lot of work to finish all the registers. I read some registers. I found 17h always confirmed it was RMII and no OVF or UNF, so the mode is fine.
  I checked 01h Bit 2, when the issue happened during power up, this bit always showed the link was not established. When I found this, I reset the chip by reset pin. Sometimes, it may need more than one reset until link establishes. After established, the issue of receiving data was cleared.
  I need to find out the root cause of no establish of link. Could you suggest which are the usual causes for this? Any register that I could read or write first to check the cause?
  Thanks.

  • Locked
  • Cancel
• Genius 13850 points

  

  Rob Rodrigues

  

  • May 15, 2017 4:25 PM

  In reply to Di Wang1:

  Hi Di Wang,
  
  There are several possible sources of link problems:
  1. Link partner transmit problem
  -verify that the connected link partner is transmitting auto-negotiation link capabilities
  -Is the link partner in auto-negotiation mode?
  -Is the link partner capable of auto mdi-x?
  -Auto MDI-X is not supported when auto-negotiation is off, so there could be an MDI/MDI-X issue as well.
  2. Cable length and quality
  -Extremely short cables, and very long cables can sometimes pose issues with certain link partners
  3. Clock quality of the 50MHz reference clock
  -Verify the 50 MHz is within the +/-50 ppm spec required
  4. MDI signal quality
  
  We do not have a TLK105 specific debug document, but the steps outlined in the DP83867 troubleshooting document can be applied.
  www.ti.com/.../snla246a.pdf
  
  Best Regards,

  Rob Rodrigues

  EFL (Ethernet & FPD Link) Applications Engineer

  • Locked
  • Cancel
• Expert 1240 points

  

  Di Wang1

  

  • May 16, 2017 1:42 PM

  In reply to Rob Rodrigues:

  Thank you, Rob.
  I changed to another clock sources, but no improvement. So I won't focus on clock.
  The link partner device is KSZ8721. It has auto-negotiation. I will try turing off auto-negotiation on both TLK105 and KSZ8721, and set 100Mbs Full-Duplex on both. I will check if the issue is cleared under this configuration.
  I found when I changed the terminal resister from 49.9ohm to 25ohm, the issue didn't happen. Does this mean anything to find the root cause?

  • Locked
  • Cancel
• Genius 13850 points

  

  Rob Rodrigues

  

  • May 16, 2017 5:56 PM

  In reply to Di Wang1:

  Hi Di Wang,
  
  This is a very interesting that reducing the termination resistor changed the behavior. This does suggest to me an issue with signal integrity on your PCB, through the magnetics, or with the cable.
  
  Please see the TLK1xx design guidelines for the cable interface: www.ti.com/.../slva531a.pdf
  
  Best Regards,

  Rob Rodrigues

  EFL (Ethernet & FPD Link) Applications Engineer

  • Locked
  • Cancel
• Expert 1240 points

  

  Di Wang1

  

  • May 17, 2017 1:05 PM

  In reply to Rob Rodrigues:

  Hi Rob,

  I found something in 0x0010. The Bit 4 always showed the Auto-Negotiation completed. But, in the receiving data issue, Bit 14 always remained in flicker. It looked the Auto-MDIX algorithm worked but didn't complete. In normal operation, Bit 14 stopped at 0, which meant Auto-MDIX completed.

  I think Auto-MDIX is close to the root cause. Below is the system block diagram, 2 pcs of TLK105 and 2 pcs KSZ8721 are used. I want to disable the Auto-MDIX. Should I disable them on both sides (TLK105 and KSZ8721)?

  I also would like to disable the auto-negotiation and set a forced mode. Should I do it on both sides as well?

  Thanks. 

   

  • Locked
  • Cancel
• Genius 13850 points

  

  Rob Rodrigues

  

  • May 18, 2017 12:40 AM

  In reply to Di Wang1:

  Di Wang,
  
  You do not have to disable auto-MDIX on both sides. If auto-negotiation is still working.
  
  If you want to disable auto-negotiation and force link speed and duplex setting, then auto-MDIX should be disabled on both sides and set as well.
  
  Best Regards,

  Rob Rodrigues

  EFL (Ethernet & FPD Link) Applications Engineer

  • Locked
  • Cancel
• Expert 1240 points

  

  Di Wang1

  

  • May 23, 2017 2:09 PM

  In reply to Rob Rodrigues:

  Hi Rob,
  I want to know the start up sequence of TLK105. I want to know the sequence of strap, auto-negotiation, auto-mdix and other initialization steps.
  Thanks.

  • Locked
  • Cancel
• Expert 6945 points

  

  Aniruddha Khadye

  

  • May 25, 2017 5:20 PM

  In reply to Di Wang1:

  Hello Di Wang,
  
  After power up and crystal stabilization the PHY samples the strap and then starts sending link pulses. If a link partner is connected then it will proceed to complete auto-negotiation and auto-mdix resolution, assuming both are enabled.
  
  If you disable Auto-MDIX and Auto-negotiation, do you still have no link? As Rob mentioned above, it has to be disabled on both TLK105 and KSZ8721. Did you try setting one PHY as MDI and the link partner in MDIX? I am assuming that the cable you used is a normal, straight through Cat5 cable.
  
  -Regards,
  Aniruddha

  • Locked
  • Cancel