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.
