• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 32 subscribers
  • Views 916 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DS90UB954-Q1EVM: DS90UB954-Q1EVM: I2C Forwarding Issue from NVIDIA Jetson TX2 Attached To DS90UB954-Q1EVM board

Matthew Bahnsen
Prodigy 150 points
Part Number: DS90UB954-Q1EVM
Other Parts Discussed in Thread: DS90UB953-Q1EVM, , ALP

Hello, I have a system using the DS90UB954-Q1EVM and DS90UB953-Q1EVM Serializer/Deserializer pair with an NVIDIA Jetson TX2 setup as follows:

I need to be able to send I2C read and write commands from my TX2 over the FPD Link to a camera sensor I have attached to the serializer on the remote side. The TX2's I2C speed is 1 MHz. I have the serializer's speed set slightly faster. The camera and serializer have the same I2c address, so I have changed the serializers address to something to deconflict. 

Right now when I try to send an I2C command from the TX2, it is received by the deserializer and sent over the FPD Link where the serializer rebroadcasts the command to the camera sensor. The camera sensor acknowledges the first byte, but then nothing happens. The SDA line on the Deserializer side goes low indefinitely and the deserializer seems to lock up. I can no longer communicate with it using the Analog Launch Pad software and I have to power cycle the whole thing. The serializer does not seem to be affected. I have attached a diagram below to show the I2C transaction on an oscilloscope: 

I need this I2C traffic forwarding feature to work properly with the NVIDIA TX2 in order to fully implement this Serializer/Deserializer pair. 

  • 0
    TI__Genius 11340 points

    Hello,

    It looks like the image sensor is holding the SCL line low. Does the camera also support 1MHz I2C? What are your pull-up resistor values?

    Best,

    Jiashow

  • 0 in reply to Jiashow Ho
    Prodigy 150 points

    Hello,

    The camera module itself does not contain any pullup resistors, the pullups are provided by the Serializer board (1.21k each). The camera can handle i2c speeds of 1 MHz. The serializer SCL line eventually is released after sometime, but the SDA line on the deserializer side is forever held low.

    I have actually been able to forward i2c commands from the Deserializer to the camera and gotten a response at this speed.  I have been able to see this work because the serializer's default remote address is the same as the camera's address (0x18). In order to get around this, I have to change the serializer's address each time to deconflict. However, in the ALP software, on the "Remote Registers" tab, I can click "Display" and the deserializer polls what it thinks is the serializer's address, but is actually the camera's address. I can see a bunch of reads on the oscilloscope and the camera replying at 1 MHz the contents of all its registers. So the deserializer to camera i2c forwarding works just fine, just not my NVIDIA TX2's I2C to the camera. Does the deserializer side need to be slower? 

  • 0 in reply to Matthew Bahnsen
    TI__Genius 11340 points

    Hi Matthew,

    You can change the serializer address in ser register 0x00 to avoid conflicts with I2C writes. But the best way to do this is to physically change the IDX pin.

    Can you try lowering the I2C rate as well? 

  • 0 in reply to Jiashow Ho
    Prodigy 150 points

    Hello again,

    I tried lowering the I2C bus speed on the serializer side to 100 kHz ( I am currently unable to change the I2C speed on the TX2 side) and still no success. I was wondering if this was another issue with the I2C host on the deserializer side not able to support the clock stretching feature. I ran into this problem on a previous post with a different i2c host device. If the I2C host does not support clock stretching, is the deserializer supposed to just completely lock up and go unresponsive like it has? What could be causing that issue? 

  • 0 in reply to Matthew Bahnsen
    TI__Genius 11340 points

    Hi Matthew,

    Thanks for bringing this up. You're right, this is the exact behavior for clock stretching. You can reference Figure 9 in this app note: 

    Could you ensure that the SoC can support clock stretching?

    Best,

    Jiashow

  • 0 in reply to Jiashow Ho
    Prodigy 150 points

    This application note is very helpful, thank you. I will need to figure out how to get my NVIDIA device to support the clock stretch feature. 

    I appreciate the helpful feedback, thank you