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.

SN65DSI85: I2C communication issues

Part Number: SN65DSI85
Other Parts Discussed in Thread: SN65DSI83, SN65DSI84

We started using the component in a design without any kind of problem, when we moved to a new board we completely lost the I2C communication with the device.

The new board has same CPU, same schematics and layout for the SN65DSI, but different number of devices and routing for other devices on the same I2C bus.

After removing any other kind of possible errors (including cutting I2C traces going to other devices) we noticed that the part is EXTREMELY sensible to SCL fall time being too step. Any other part in the same bus was operating in the same condition.

This may be expected in I2C fast mode because the SCL fall time is constrained in its minimum value, but in my understanding it is unexpected in I2C normal mode (<= 100kHz) as per I2C specs. After more digging it ended up that the first board had enough trace and device capacitance on SCL to fit in the fast specs, so, it seems that the SN65DSI85 expects SCL fall time to be constrained to fast mode specifications also in normal mode. I wonder if this can be confirmed  by TI.

The solution for our design was to relax the drive strength of the I2C and avoid the linux GPIO recovery (driver capability) which, in our case, both made the SCL fall time around 4.5ns instead of the 6.5ns (1.8V). After patching the configuration and bringing the fall time over 6.5ns, the device started to respond properly.

I expect this condition applies also to SN65DSI83 and SN65DSI84.

I hope this post will help others in the same unlikely situation.

  • Hi,

    The DSI85 I2C interface conforms to the two-wire serial interface defined by the I2C Bus Specification, Version 2.1 (January 2000), and supports fast mode transfers up to 400 kbps.

    Do you have a scope waveform of SCL and SDA you can share? Are we also sure we are meeting the setup and hold requirement?