TCA4311A apparent bus corruption

I should probably mention that the TCA4311's are usually powered down - and then get switched on, and then enable gets activated.
The issue is independent on which / both TCAs are on.

Have you tried reducing the 5.6k pullups on the B-side as well? it seems like there is some bus-contention happening which is pulling down the clock lines.

Thanks,
Rajan

No, I haven't - but these 5.6k pullups are isolated from the second TCA4311, and therefore shouldn't have any impact (at least if it's off).
Still, I don't see a difference in the reaction to switching on TCA nr 1 with TCA nr 2 (the one with the 5.6k pullups) switched on or off.

One other slightly odd observation is that if TCA nr 2 is switched ON, I loose one I2C device on the 3.3V bus while probing, but I don't gain the device it's meant to switch on. (they don't have the same ID).

Thanks for your help!

Hello User,

Would you be able to supply a basic sketch/block diagram of your I2C bus? ANd point out where these above scope shots are measured at?

It sounds you have two TCA4311As connected to each other?

Depending on how they're connected, it may be a result of having two rise time accelerators on the bus if this issue occurs as soon as you enable the device

Hi Jonathan,

Sure, I hope the diagram below is helpful. The scope shots are on the main 3.3V bus, however, the waveform looks almost identical behind TCA No1.

As a comment:

- while shown to have 2 devices connected TCA No1 currently has no devices connected, they're not plugged in to simplify debugging

- while all the pulldowns are 1.2k in the schematic, we've tried difference values and combinations for each of them.

- disconnecting the TCA9406 from the I2C bus (lifting the pins up) does not change the behaviour.

- the TCAs are switched off completely, and are powered on with their respective partial-powerdown section. the enable is then activated by software for one, by RC delay for the other one. The issues start after enable is activated.

The symptoms are:

- Switching on TCA No1: (TCA No2 off) bus is completely dead. Waveforms as shown in the image, recorded on the main 3.3V bus. No transfers possible any more. <-- this is the main issue

- Switching on TCA No2: (TCA No1 off) bus is still operational, but one device from the main bus goes missing (doesn't react to chip ID) and switched on device does not appear. <-- this is some issue, but not the main concern.

- Switching on both TCAs yields the same results, no additional problems.

Thanks for your help,

Kai

Kai,

The diagram helps significantly.

Sounds like you're having an issue whenever you power on 1 of the TCA4311As at a time. Would you be able to grab a scope shot of both sides of a TCA4311A when you have the issue where a device goes missing? You say only 1 device goes missing, which makes me wonder what the I2C waveform looks like on both sides of the TCA4311A (makes it easy to see what gets through the device and what doesn't).

Another thing to check, take a look at both sides of the TCA4311A when you disable the device. Check and see if both sides are idle and at a high voltage (3.3V stable on the line on both sides when no communication is taking place). If one side is stuck low or at a lower than normal voltage, we have a starting point.

One thing I notice, is that you don't seem to be using these TCA4311As as hot swap devices. Looks like you're using them as a I2C buffer with an enable. Is this correct? If so, you may want to look at other buffers such as the TCA9517 or the TCA9617B (first is 400 kHz, 9617B is 1MHz) and is designed to be used in these fashions. The TCA4311A is designed for hot swapping and not necessarily a normal buffer.

Hi Jonathan,

Good. I guess my intended ASCII art in the first post wasn't all that good after all.

I will do, and post those, hopefully later today. I have similar shots for the case where the whole bus is stalled (with the other TCA), but it just seemed to follow the other traces, as below. (yellow being behind the TCA, blue the main bus, both traces being SCL).

What is maybe an important clue is that the time low for SCL is the correct 5 us (100kHz bus) but the time high on SCL is lost - the master directly seem to start driving the next SCL cycle, which seems to be related to the behaviour of the TCA.  Also notable is the reasonably high logic low, which is around 0.5 V. The high value seems to be reasonably close to 3.3V.

As some additional information we seem to have been able to keep the bus from becoming unusable by adding 390pF from SCL/SDA to GND on the main bus. I suppose this reduces the rise time of the bus far enough to prevent the rise time accelerators to kick in - not neat, but at least it doesn't crash. With that setup, the missing device remains there, but the new device doesn't appear. We're about to test whether the other TCA can add the missing devices, or whther they remain isolated as well.

Mmh, true on the hot swap. I think i went for this because I wanted safety for being able to safely power off and on the TCA, assuming that the hot-swap device would be safer than a normal buffer.The TCA4311 should still be able to do this, we're just not using the live-insert options then, is that right?

Given that they are not pin-compatible and we can't re-iterate the PCB in time, I'm afraid we need to make due with the 4311 (or pin-compatible devices).

Hey there,

Do you have any additional feedback? Anything discovered from further testing?

I looked and we unfortunately do not have any P2P devices with the TCA4311A.

I would like to get to the bottom of this, as I have not seen this before.

One thing that catches my attention is that it looks like the RTAs activate and then get pulled down (Notice how the voltage never makes it all the way up. This looks like a device is trying to pull the bus low while the RTAs are trying to pull i thigh). This may be a weird result of a device trying to stretch the clock.

Do you have the ability to isolate slave devices from the bus?
Perhaps it would be a good idea to try removing slave devices 1 at a time and enabling the TCA4311A to see if you still get this behavior. It may also be a good idea to remove/disconnect all slaves, enable both the TCA4311As and see if you get this waveform. If you don't, add 1 device at a time until you can replicate this.

Another option to try is to see if you get this waveform when you bypass the TCA4311A altogether. Disable the TCA4311A and short the SDA/SCL lines through it, so that the slaves are connected directly to the main bus (should be ok since they are on the same voltage node). DO you get artifacts in this situation?

Hi Jonathan,

Sorry for the delay - I was tangled up with other things for a while, but now got hardware and test kit around.

I've removed the TCA9406 from the board in an attempt to isolate the problem, and that seemed to be it - the TCA4311 seems to switch the device behind it flawlessy, the waveforms look clean.

Unfortunately I didn't have a look at the i2c waveforms on the 5V side, and I've broken the 9406 while removing it, so I'll need to get replacements first before being able to do more tests.

I don't have a suspicion yet on why the 9406 does this - do you have any suggestions what might be the issue?

Thanks,

Kai

Hello Kai,

If removing the TCA9406 fixes the issue, that points to the fact that the TCA9406 has RTAs on it. The TCA9406 is not a buffer, but is actually a switch with rise time accelerators (RTA) on it. You would likely have better results if you replaced the TCA9406 with a truly buffered repeater/translator, like the TCA9517 or similar.

I suspect the root cause is that with many RTAs on a lightly capacitive bus, your rise time is violating I2C spec (too fast of a rise time, probably). This can cause issues with the TCA4311 not realizing the bus is high, and then not releasing one side.

Another test worth trying to see if my theory is correct would be to add a sizable amount of capcaitance to the 5V side of the bus. Try adding 200 pF (or somewhere around it) to see if your communication waveform across the TCA4311A looks better. I'm growing suspicious that the 5V side rise time is too fast with all those RTAs on the bus. I2C spec has a minimum rise time of 20 ns for fast mode.

Hi Jonathan,

Is there a normally buffered translator that would be pin compatible to the TCA9406? The TCA9517 doesn't seem to be.

I could imagine so - I have very strong pullups (just 1.2k), which might be excessive. The voltage drop over series resistors points to a 10mA current when low, which seems unnecessary high.

When testing the issue could be resolved by switching oscilloscope probes from x1 to x10 on the 3.3V side, due to the change in capacitance.

As soon as I get my new 9406s I will check adding capacitance and/or increasing the pullups on the 5V side.

Thanks,

Kai

Kai,

Unfortunately not. The TCA9406 shares a unique package.

Since your voltage drop points to a 10 mA current, you are correct that your pull-ups are too strong. I2C maximum current for <400 pF of capcaitance is 3 mA maximum. In some extreme cases 6 mA.

In that case, since you have so many RTAs on your bus, try changing the pull-up resistors to 10k. You might actually be able to go higher, depending on your loading conditions.

If switching from x1 to x10 fixed the problem, this is more evidance that points to a very fast rise time violating I2C spec. There are a few ways to slow it down:

1) Increase pull-up resistance to get a weaker pull-up current (the RTAs will do most of the work on the rising edge, so you don't need low values).
2) Add capacitance to increase the RC time constant.