ISO1641: Unable to communicate with one specific slave device

Arush Thomas

Part Number: ISO1641
Other Parts Discussed in Thread: BQ76942, BQ76952, , ISO1640

Hi all,

I've been testing an ISO1641B IC to perform isolated I2C communication, between an MCU Master, and a BQ76942 AFE slave (address 0x60). Unfortunately I have been unable succeed; It appears that the isolator is failing to pass some clock pulses from SCL1 to SCL2. I've attached an image from my oscilloscope that demonstrate this problem:

Missed SCL results in BUS BUSY

Pink: SDA2 (slave)
Green: SDA1 (master)
Yellow: SCL2 (slave)
Blue: SCL1 (master)

Some Clocks transmitted by the Master (Blue) are not passed on to the Slave (Yellow). After this occurs, the bus enters a BUS_BUSY state, and no further communication is observed. Additionally, every time I restart the Master and Slave, I observe the same waveform - the exact same SCL pulses are clipped every time.

VCC1 is 3.3 volts with respect to GND1. SCL1 and SDA1 are pulled up to VCC1 with 4.7K resistors.
VCC2 is shorted to VCC1, and GND2 is shorted to GND1.
SCL2 and SDA2 are pulled up to VCC2 with 2K resistors.

I have tried numerous resistors on the Slave side: 2K, 4.7K, 6.8K, 10K and 20K. All show very similar symptoms, of missed SCL2. Master side always has 4.7K pullups to VCC1

I have tried baud rate 50kHz, 100kHz, and 400kHz. Here, too, SCL clocks are often missed.

I have also tried a 5v supply to VCC2, to no effect.

There's a bit more confusing behaviour, I'm hoping this might help to narrow down the problem:

Slave removed from bus When the BQ76952 slave is removed from the I2C bus, the isolator does appear to work. SCL2 exactly matches SCL1.

Communicate with non-existent address Similarly, when I attempt to communicate with address 0x40 (not present on the bus), SCL2 matches SCL1.

I am able to communicate between the MCU and the Slave without the isolator, when I connect the MCU's I2C bus directly to the Slave's I2C bus. So surely the Slave device does work. Similarly, I am able to communicate with a different slave (MPU9250 sensor) through this isolator without trouble. So it appears the isolator does work, too.

Why do some of the SCL pulses get missed, and how may I resolve the issue?

Thanks,

Arush

over 1 year ago

0 Andrew J over 1 year ago

TI__Mastermind 29535 points

Hello Arush,

Thank you for the detailed debug do far. I will review this in detail and get back to you tomorrow.

The first thing I would check is to see if you are overloading the C1 or C2 load capacitance values of the isolator. The side 1 I2C lines only intended to have a direct connection to the MCU. How many devices are connected to Side 1 of the isolator?

[FAQ] ISO1640: Why are the maximum load capacitance and load current ratings for Side 1 of the ISO1640/ISO1641 less than Side 2? - Isolation forum - Isolation - TI E2E support forums

Best,
Andrew

0 Arush Thomas over 1 year ago in reply to Andrew J

Prodigy 40 points

At the moment, Side1 only has one MCU, in Master Mode. Side2 only has the BQ76942, as a slave.

As a sidenote, I will later be connecting a slave to side1, as well. The end goal is for the MCU to have isolated communication with the first slave, and non-isolated communication with the second. Is this likely to cause a problem?

0 Andrew J over 1 year ago in reply to Arush Thomas

TI__Mastermind 29535 points

Hello Arush,

It may cause an issue. For best datasheet performance we recommend that side 1 of the isolator has an exclusive connection to the MCU.

We should be able to rule out the capacitive loading for now since it looks like there is only the MCU and the BQ76942 device on the bus. In general, these I2C isolators do not see the protocol and will simply pass the signal to the other side of the isolator. Therefore there is no clear reason for the Isolator to miss an SCL bit unless the slave device was attempting to drive the clock line. From the scope capture the failure is on the slave side of the isolator. Is there any reason for the BQ76942 to be driving SCL low and causing a bus contention?

Best,
Andrew

0 Arush Thomas over 1 year ago in reply to Andrew J

Prodigy 40 points

Hi Andrew,

Thanks for the heads up.

As far as I'm aware, the BQ76942 does not drive the SCL under any conditions.

0 Andrew J over 1 year ago in reply to Arush Thomas

TI__Mastermind 29535 points

Hello Arush,

There is not a lot more information to go on here from the previous post.

I can only provide the following further comments and suggestions:

I suspect that there is some error on the protocol level. Since I do not see a valid transmission from SDA2 to SDA1 it looks like the Acknowledge bit is being overwritten. The shelf in the green waveform is a result of the side 1 VOL region.
As a result, the acknowledgement bit and Stop bit (in the following packet) both look like they are being missed. To me this suggests a protocol level issue. Especially since it the (pink) SDA2 line is held low after the data stops.
Also, the last two scope shots (when the BQ device was removed) show that the yellow signal was not being pulled high after the transmission ended. Which means that there is not "stop condition" in the packet.

The only recommendations from this point would be test a different I2C isolator, or making a new thread for the BQ76942 to see if they can provide further insight.

Best,
Andrew

0 Arush Thomas over 1 year ago in reply to Andrew J

Prodigy 40 points

Hi Andrew,

Thanks for your insight! I hadn't noticed the ACK bit corruption till now. I just re-tested, and it is consistent. The first transaction always has that corrupted ACK, along with the same missing SCLs.

Anyhow, I have made a new thread about this topic on the Power Management forum, as you suggested: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1341792/bq76942-isolated-i2c-communication-with-iso1641

I shall also try out some other I2C isolators, see if I can make some progress that way.

Thanks,

Arush

0 Andrew J over 1 year ago in reply to Arush Thomas

TI__Mastermind 29535 points

Hello Arush,

Thanks for letting me know. Also, please note that when I said try a different Isolator, I am suggesting trying a different ISO1641 (this is an A-B-A swap) to see if the problem continues with a new device or the issue follows only the original device.

Regardless I will close the thread for now. Please feel free to create a new thread or follow-up here if you have further questions.

Best,
Andrew

+1 Arush Thomas over 1 year ago in reply to Andrew J

Prodigy 40 points

Hi Andrew,

The issue has been resolved. It turns out that the BQ76942 does, indeed, drive the SCL signal low, to perform Clock Stretching. Since the ISO1641 has a unidirectional clock, the MCU was not able to support the clock stretching.

The solution is to use an ISO1640 instead, which supports a bidirectional clock. This in turn allows Clock Stretching to work on the bus.

For now, on my testbench, I've been able to establish communication, using a second ISO1641 IC. I passed my SCL signal through the second isolator's SDA1,SDA2 pins. I hope this information helps anyone else facing the same trouble.

I am yet to find an explicit explanation for the ACK bit corruption, but I no longer face that symptom.

Thanks for all your help!

Best,

Arush

0 Andrew J over 1 year ago in reply to Arush Thomas

TI__Mastermind 29535 points

Hi Arush,

I am glad that I could help you towards a solution and thank you for coming back to update the post with your solution! Remember to click "This resolved my issue" on the suggested answer or one of the replies which will make the post easier to find for future users.

Best,
Andrew