TCA9555: Issue with I2C bus

Sahil,

Interesting. Is there any chance you'd be able to share an image of the oscilloscope view when you see SDA lock up? Does SCL continue to toggle?

Does this happen while TCA9555 is controlling SDA, or while TMP275 TM4C129ENCPDT is controlling SDA?

Best,

Danny

Hi Sahil,

Thank you for your question. 

I really appreciate the fact that you listed out the addresses of each IC. This would have been my first suggestion to look into because at first it sounded like a bus contention issue. 

Sahil said:

I removed two TCA9555 chips and left only one TCA9555 chip on board and I still see the same problem.

Have you tried to keep all three TCA9555 in operation but remove the TMP sensor to see if this fixes the issue? 

Sahil said:

I confirm we have 4.75kR pull-ups on SCL and SDA lines. When I scope the SDA and SCL lines, I see time to time the SDA line will not come back High (From Low to High).

Pull-up resistance seems to be well-valued. I don't see a problem with your choice of resistance.

Question: What does the I2C communication distance look like? Are you communicating across a long cable to reach the temperature sensor? 

Question: Could you provide a scope shot of the error that you are seeing? Can you also provide a schematic of your system? Are there any I2C buffers before the 3 x TCA9555 and TMP275 sensor? 

Regards,

Tyler

Hi,

Please see my answers below;

I removed all the chips including the TMP Sensor as well as two TCA9555 so that the board has only one I2C chip at 0b000 address.

The chip is on same board about 4 inch away from uController I2C bus lines. The pull-up resistors are next to the chip.

There is no buffer or any isolator chip. The connection is direct from chip to microcontroller at 4 inch distance. 

when I debug, I see no errors reported by micro controller as the DATAACK, ADDRACK and ERROR bits are all zero. However I see the Busy bit always High. Capturing the event is tricky because after first transaction when the controller boots up, the SDA is sits at low and doesn't transition from Low to High, the microcontroller doesnt initiate another I2C transaction. I do see few times the SDA transition from Low to High during initial I2C few clocks. 

Hi, I am able to collect snapshot. Please note for the following snapshot, the controller is communicating with TCA9555 chip at address A2:A1:A0: 0b011 and I am reading io Port 0 of the chip located at 0x00 address.

I see two different issues.

First image shows the chip is asserting ACK 3 times and starts sending data to micro controller. However the microcontroller doesnt assert ACK at the end of the transaction. The SDO successfully transitions from Low to High at the end of the packet. However micro-controller doesnt assert ACK.

The following snapshot shows the chip doesn't assert ACK and the SDO line stays low. I also note one of the clock signal is missing/half way. Please keep in mind, the chip is at 4 inch distance with no buffer or isolator. The connection between the chip and microcontroller is pin to pin direct.

Waiting for your help.

Thanks

Once the SDO goes low, microcontroller is no more able to communicate any further.

The clock rate in above pictures are at 100kHz. I have tried 400kHz as well.

Here is the schematic. Please note the Chip address on the schematic is for Chip 1(Address 0b000) while above snapshots are for Chip2 (Address 0b011).

In the first image, the missing ACK at the end is OK; this is how the master signals to the slave that it does not want to read more bytes.

In the second image, the is a spike on the clock line. I suspect that the slave reads this as a clock pulse, while the master does not, and both are out of sync.

Where does this spike come from? The TCA9555 does not do clock stretching; there must be something wrong with the master's I²C implementation. A low-pass filter on the line might help.

I measured the spike width to the neighbor clock pulses and it seems this is not a spike but a half-way clock. This means this halfway clock is not recognized by TCA9555 chip and hence it is expecting one more clock to end the transaction and release the SDO line. The question is why this half-way clock happens some time. Any idea ?

Additionally, you may have noticed some of the data pulses on SDO are not proper pulses but looks like spikes.

Hi Thanks for your reply. I have some further info to share. I see even with the Half-Way Spiky clock the SDO line will recover in some cases. Does it mean the issue is not related to the half-way spiky clock, or probably in some cases it might be just on the threshold edge that the device releases the SDO line ?

Your scope may not be fully sampling the high point of the false clock edge. It seems like that pulse is generating a stuck bus condition. Normally there are 50ns deglitch filters so if the pulse width is below 50ns all devices should ignore pulses like this. To me, it seems like the MCU thinks a clock pulse has been generated (it only makes 8 clock pulses in the last transaction) while the I2C device is ACKing in this case and waiting for the next clock pulse. 

You should be able to unstick this by toggling the SCL line. If you can't do this from a software perspective TI does sell a device with stuck bus recovery (TCA4307) which will detect a stuck bus and resolve the issue by toggling SCL for you.

-Bobby

Hi,

I think the issue is not chip related. I am talking to a dummy chip by sending A2A1A0 address that doesnt exist on the chip and I still see that spiky-clock pulse randomly from time to time. Do you think if this could be a layout issue ?

No; that spike is generated by the master's hardware by driving the clock output high for a short time.

As a workaround, add a low-pass filter (e.g., an RC circuit) to the clock line so that the spike never exceeds V_IL.

Hi Sahil,

Have you had time to process all of the points we have made here? Have you arrived at a solution yet?

Regards,

Tyler

Hi,

Thanks for your help. It seems the issue is some ground loop related. I am still working on it.

Sahil,

Please respond back here when you receive updates.

Regards,

Tyler