TCA9617A: I2C bus gets hanged.

Hey Rajneesh,

For the TCA9617 device, B side has a ViL of 0.4V while TCA9517 switches between 30% of VccB and 0.4V (internally they work differently). I suspect this may be the problem. You should probe your B side of the TCA9617A and see if the low voltages are below 0.4V when you are trying to send a low from B to side A side. If this is the problem then what you could do is use a weaker pull up resistor on B side to make the master/slave on that side drive a lower VoL.

Please post from waveforms of both A and B side so we can confirm if this is the issue.

Thanks,

-Bobby

Hi Bobby,

The VIL on side B as measured on scope is well below 300mV. The snapshots of the waveform are attached. The waveform shows the transaction for reading 2 bytes of data from address 77h. The bytes read are 08h, 08h.

The below waveform is of side A.

The below waveform on side B

Regards,

Rajneesh

Hi Rajneesh,

In your design, TCA9617A is buffering the Master's communication to the B-side. In the second scope-shot you posted, the master is reponsible for the clock signal (green) and the initial addressing and read command (two yellow down pulses at the beginning) and the ACK (small yellow rise to the right of the second cursor). The voltages at these points appear higher than what is being driven by the slave device on the same side of the buffer. We are concerned that this voltage is not low enough (below 0.4v) consistently. Increasing the value of the pull-up resistors on this side (decrease the strength) will allow the buffer to drive these voltages consistently to a value that will be recognized by the slave. 

Regards,

Eric

Hi Eric,

The slave connected on the side B is an IIC hub PCA9548A, for which the VIL is upto 0.3xVCC with the VCC at 2.5V. The VOL(circled in red by you) is 500-600mV which is in range of the accepted VIL of slave.

Also, as per your suggestion, I tried with different pull up resistors. The VOL doesn't seem to change. Attached is the waveform with 1.2K  and 2.2K pull up (older pull up 1K).

With 2.2K,a different transaction was done.

Thanks,

Rajneesh

Hey Rajneesh,

Do you have scopeshots of the I2C bus getting hanged up (and I2C transaction right before the hang up)? From what I can see in your scopeshots, the TCA9617B device is working properly. The 500~600mV offset you are seeing is from the TCA9617B's static voltage offset.

One thing I could think of which could possibly cause the bus to get stuck is the fall time accelerator we have on the TCA9617B. The fast edges could cause some kind of cross talk on traces close to the SDA/SCL lines of our device.

You also mention an I2C switch PCA9548A. Are you enabling multiple channels of that switch or one at a time? Another thing I could think of is if you enable multiple channels, the channel's pull up resistors would be in parallel with each other when driving low. This could cause a larger VoL. If you have B side connected to the switch this VoL could be larger than ViL of TCA9617B and the low you are trying to pass through could be missed.

A block diagram of your I2C tree of when the I2C bus gets stuck would be helpful to look at as well.

Thanks,

-Bobby

Hi Bobby,

We are not enabling multiple channels on PCA9548A. Even the VOL of the PCA9548A is in range of the next slave device.

I am attaching the scopeshots before the bus hangs.

Can we use a diffrent IIC buffer other than TCA9617A? Can you please suggest an IC which is similar to TCA9517 which can translate from 1.8V on sideA to 2.5V on side B? Is TCA9801 a suitable replacement for TCA9617A?

Regards,

Rajneesh

Hi Bobby,

We tried the TCA9801 and TCA9617B as well.We are operating the bus at 400KHz  But still, the device read is not proper. But with TCA9517, the read write happens most of the time. Please suggest some solution/alternate parts.

~ Rajneesh

Hey Rajnesh,

The only other device which would be pin to pin is TCA9509 however it requires a 1V difference between A side and B side and does not meet your 2.5V requirement.

A non pin to pin solution would be to try PCA9306.

-Bobby

Hi Bobby,

There is a new finding on the IIC bus. I am attaching the IIC scheme below. 

Here, IC A is TCA9517 (translating from 1.8V to 3.3V) , B is TCA9617 (1.8V to 2.5V), C is IIC hub ,PCA9548A. It was observed, while having an oscilloscope probe connected to the SDA line on the 3 pin HDR (after A), the transaction went fine on the bus. So, tried to load the SDA line with 5pF / 10pF capacitors near B (between pin 3 and 4), but it didn't help. However, on placing a 10pF capacitor on SDA line after the IC A (TCA9517),from the header (as shown in dotted box), the bus is not hanging. The same behaviour was observed when IC B was changed to TCA9803 (the pull ups on side B were removed).

Can you provide an explanation for the behaviour? Can TCA9517 and TCA9617B be interfaced in daisy chain (with side A of both ICs),as shown in figure?

Update: Replaced IC A also to TCA9803 along with IC B, the bus works fine. Still, looking for the root cause. Please respond.

Regards,

Rajneesh

Hey Rajneesh,

This is still quite difficult to pinpoint what the root cause is without seeing an o-scope of the failure. I think we may want to look at the SDA lines after A, before A, and between B and C. I'm wondering if the unwrapping/unwinding affect of the buffer may have something to do with this though that would require B side of either of those devices to be pulled below the 0.4V ViLc threshold.

-Bobby