• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 615 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.

Original question:

DS92LX1622: DS92LX1622 I2C communication problems

DS92LX1622: .

David Phillips1
Prodigy 135 points

Part Number: DS92LX1622
Other Parts Discussed in Thread: DS92LX1621

We have a DS92LX1621 -> DS92LX1622 display mode link that works well other than the I2C master at the deserialiser. The SCL frequency is left at the default frequency of 100 kHz. The I2C bit rate changes back and forth between the expected 100 kHz and 600 Hz. 600 Hz is far lower than can be achieved by programming the I2C bus rate register. Throughout this the recovered PCLK remains at 40 MHz and LOCK is high. I believe that the I2C clock is derived from an internal 25 MHz oscillator rather than the recovered clock anyway. On some deserialiser boards the I2C slave device copes with this, on others it doesn't. DO you have any ideas what the problem may be ?

  • 0
    TI__Guru** 103215 points

    Hello David,

    It could be possible that the remote NACK timeout is getting triggered. Could you try adjusting register 0x06 on the 1622 to disable the NACK timeout?

    Best Regards,

    Casey 

  • 0 in reply to Casey McCrea
    Prodigy 135 points

    Hello Casey,

    Clearing the REM_NACK_TIMER bit does seem to have fixed the problem. I still see very slow I2C transactions ( about 1 kHz SCL) but our system controller is no longer reporting read errors. In development I can only check a couple of systems today but I've asked that more are made available. The manufacturer of the I2C slave device reckons that their NACK timeout won't go beyond 8 ms so we thought that leaving the default timeout of 25 ms would be fine. Does your I2C master deal with slow slave devices by reducing the SCL frequency, i.e. is what we are seeing expected behaviour ? Thanks for your help.

  • 0 in reply to David Phillips1
    TI__Guru** 103215 points

    Hello David,

    Our devices utilize I2C clock stretching to enable remote read/writes over the bidirectional control channel. You can find more information about the mechanism here: http://www.ti.com/lit/an/snla131a/snla131a.pdf

    I think for very very slow I2C transactions the timeout may occur due to the round trip delay and clock stretching so increasing the timeout value may help with this situation in your system.

    Best Regards,

    Casey