• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 465 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TLK2711A clock recovery issue

David Shan
Prodigy 30 points

Greetings,

Please help look at the tranmit/receive issue.

In our system(board), there are 4 TLK2711A chips.

We test that the chip TLK2711A could work well (transmit/receive data) in loop-back mode.

We try to send data between two TLK2711A chips, chip A and chip B, chip A sent data to chip B, and chip B sent data to Chip A simultaneously.

The two chips can't receive the data correctly.

We found that the recevied recover clock is not stable, and frequently inverted 180 phase.

If we disable chip A to transmit data to chip B, and only enable chip B to transmit data to chip A, chip A can receive the data correctly. 

Could you please help look at the above issue?

Thanks a lot for your help.

Best Regards,

David

 

 

 

  • 0
    Prodigy 30 points

    Could you please someone give me some clues on this issue?

    Thanks a lot!

    David

  • 0 in reply to David Shan
    TI__Guru 62920 points

    Hi David,

    Are you able to look at the differential RXP/RXN signal when the issue occurs?  This would help us verify whether or not there are some issues in the physical link itself (such as crosstalk, loss, etc.) that are causing the receiver input to not comply with the input specs.  It might also be good to check the power supply rails, since it is possible that the current draw from multiple enabled devices is pulling the supply voltage below spec.

    Also, what kind of transmission media are you using for the links from chip A to B and chip B to A?  Is it a PCB trace, cable, etc.?  What is the length?

    Are the clock signals supplied to each TLK2711A chip derived from the same source?  If not, what is the frequency accuracy of the different clocks?

    Have you done any testing with the device's internal PRBS data generators and verifiers?  Using these instead of an external data source can help verify the source of the problem, since it bypasses the parallel interface of the device and only uses the serial interface.  If the problem persists, it is related to the serial link.  I think this is more likely, since serial link issues may cause an erratic recovered clock.  If the problem is not present in PRBS testing, though, it could be related to the parallel data (maybe set-up/hold timing violations or insufficient high/low signal amplitudes).

    Regards,
    Max Robertson
    Analog Applications Engineer
    Texas Instruments
    m-robertson@ti.com



  • 0 in reply to Miguel Robertson
    Prodigy 30 points

    Hi Max,

    Thanks a lot for your prompt reply.

    We checked the circut again, it maybe caused by the clock jitter.

    We changed the clock signals supplied to both devices to derived from the same source, the issue resolved.

    Thanks again for your help.

     

    Best Regards,

    David