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.

TCA9517A: TCA9517ADGKR

Part Number: TCA9517A
Other Parts Discussed in Thread: TCA4307, TCA9517

Hello,

I am using this IC TCA9517ADGKR and accidentally in the schematic I swapped pins 2 and 3. To fix it, it was easier for me to swap pins 6 and 7 in the board and I did that. So now SCLA and SCLB are on either sides connected to I2C data and SDAA and SDAB on either sides are connected to I2C clock. It appears to work.

However, we are seeing I2C failure on of our connected devices through this repeated and the data line gets pulled to 0 after some hours of operation. 

What I am seeing may not be related to TCA9517ADGKR but is it okay to have the SCL/SDA lines swapped and are they identical buffers? Or is SCLA/SCLB meant to be connected to I2C clock and SDA/SDB to I2C data?

Thanks,

Divakar

  • Electrically, SDA and SCL are identical.

    It appears some I²C device's state machine got locked up. You have to check which one sinks the current.

  • Thanks,

    I am looking at the B side in a working condition and the SCL/SDA 0 is around 0.5V. Is that okay? Section 11 seems to say it must go lower than 0.4V. Since the failure happens after a long time it may not be the re-driver but want to rule it out. Below is the schematic. A side is pulled up near the processor with 1K

  • On further investigation, I think this 0.5V is driven by the TCA9517A as I do see the slave drive the 0 much lower and goes almost close to 0V. It is matching your figure 11 of the data bus. Is there a way to clear the I2C device from a stuck condition?

  • It might be possible to send a few pulses on SCL (the TCA4307 does this automatically). But the safest way is to reset the device (with a reset input, or by power-cycling it).

  • I am trying to avoid a reset as other parameters of the IC works fine and just the I2C communication is failing. Does this mean even in my current state when it is stuck (the TCA4307 does this automatically) is being done? If that is the case it isn't working and recovering the device. 

    Regards,

    Divakar

  • Hi Divakar,

    Which line is getting stuck? The SDA or SCL line? The TCA9517 device basically just copies the driver from A to B or B to A, it doesn't have any kind of recovery function. The TCA4307 device you mentioned does have a stuck bus detection in which if either SDA/SCL is stuck low, the device will disconnect both sides from each other (so if the downstream device is causing the stuck bus, the I2C controller on the opposite side should be able to gain control of the bus). After the disconnect, the TCA4307 will generate clock pulses on the downstream side to try to reset the I2C device's state machine and then it will generate a stop condition. If this doesn't unstick the bus, then the TCA4307 will remain disconnected from the downstream bus until the problem resolves itself (like if you reset the downstream bus sticker).

    Now if the stuck bus is on the clock downstream, then the TCA4307 can't unstick the bus. The best it can do is disconnect the bus so the I2C controller on the backplane can still communicate to I2C devices on that side of the bus. 

    -Bobby

  • Thanks for the support,

    the failing IC is unable to tolerate access to other devices in the middle of a transaction. We can fix it with software,

    thank you,

    DIvakar