• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 384 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.

[ DS90Ux92x ] Short Unlock Status

Kenichiro
Mastermind 9165 points

[ DS90Ux92x ] Short Unlock Status and Root Cause

Hi,

During debugging my customer set which use DS90UH925 and DS90UH926, we have seen short out of lock condition few times. The duration is around 150uS,

(LOCK pin is asserted and deasserted after 150uS.)

This causes the I2C communication failure and are now trying to identify what's going on when this happen.

Have you seen this before? It's appreciated, if you can comment on this.

Thanks,
Ken

  • 0
    TI__Genius 14015 points

    Hi Ken,

    What is the PCLK rate? How long is the cable?

    The best way to measure the robustness of the system is to measure the eye opening at the CMLOUT pins. This shows what the 926 is able to recover from the forward channel serial stream. You can enable the CMLOUT by writing 0x56 = 0x00 on the 926.

    There should be 100 Ohm termination between CMLOUTP and CMLOUTN. Compare the eye opening to the spec given in the AC parameter section of the 926 datasheet.

    Thanks,
    Jason

  • 0 in reply to Jason Blackman
    Mastermind 9165 points

    Thanks, Jason!!

    Yes, CMLOUTP/N need to be checked...but unfortunately thier design does not have accessible CMLOUTP/N lines on board. (For new design, I definetly recommend customer to have it).

    I will check the condition of PCLK and Cable length shortly.

    Thanks,
    Ken

     

  • 0 in reply to Kenichiro
    Mastermind 9165 points

    Hi Jason,

    Here is little more information from customer.

    PCLK: 37MHz (or 75MHz)

    Cable Length: 1m to 2m

    With regards to short unlock status, we have been discussing a possibility than, due to some reasons, deserializer might miss clock information (either C0 or C1, or both) of some 35bit data packets. When following valid data frames supplied to deserializer, deserializer can achieve lock condition again.

    Do you this this is the possible case?

    Thanks,
    Ken