[SOLVED] Randomly facing I2C communication failure with LTC4015

Hi all,
LTC 4015 is interfaced with microcontroller through I2C differential transreceiver circuit.
Communication breaking between controller and LTC4015 randomly.

Steps:

1. Connect SMPS and battery supply to LTC4015
2. Connect External 3.3V supply to LTC4015 DvCC pin(External 3.3V supply is coming from microcontroller board)
3. communication will be established between controller and LTC4015
4. Reset DVCC (3.3V) and 5VDC continuously.
5. Randomly communication is breaking, then observed that SDA pin on LTC4015 side holding low and SCL pin holding high.
6. After this failure if we are doing reset continuously, communication is not establishing back
7. Once we resetting both SMPS and battery supply voltage to 4015 then communication happening.
8. If removing anyone SMPS or battery supply, that time also communication is not reestablished.
9. If re initialing I2C in microcontroller firmware not solving this issue.
10. When re initializing I2C module, till differential signal output changing correctly. but LTC 4015 side (SDA, SCL not changing., LTC4015 holding SDA signal in low state and SCL signal in high state)

Observation : I think LTC4015 holding I2C SDA and SCL lines to low and high level respectively. so only when both battery and SMPS supply is removed then communication is happening.

I2C slave lockup can happen due to incorrect control sequence or electrical noise. Try I2C recovery procedure described in NXP application note.

Bus recovery sequence is done as following:
1 -Send 9 clock pulses on SCL line
2 - Ask the master to keep SDA High until the “Slave-Transmitter” releases the SDA line to perform the ACK operation
3 -Keeping SDA High during the ACK means that the “Master-Receiver” does not acknowledge the previous byte receive
4 -The “Slave-Transmitter” then goes in an idle state
5 - The master then sends a STOP command initializing completely the bus

Click to expand...

FvM said:

I2C slave lockup can happen due to incorrect control sequence or electrical noise. Try I2C recovery procedure described in NXP application note.

Click to expand...

Thanks FvM. Before going to test i need clarification on above points,

We are sending clock pulses from STM32F4 controller(Master) to 4015 IC (Slave).clock pulses are not reaching the LTC4015(slave). As i have mentioned above, We are using differential circuit(PCA9615) on both master(STM32F4) and slave controller(LTC4015) boards. when we send clock pulses from master to slave, clock pulses are sending till slave side differential input side(DSCLP and DSCLN). but slave side differential output(SCL) is not changing(SCL), slave deivce(4015) holding SCL to high and SDA to Low.

When resetting input power to master controller, still slave holding SDA and SCL to low and high level respectively.

SDA/SCL is changing, only after resetting slave controller input power .

Hi,

slave deivce(4015) holding SCL to high

Click to expand...

No I2C slave device is allowed to hold a signal HIGH.
Valid outputs are LOW and HIGH-Z only (open collector, open drain). HiGH level is generated only by the pullup.

Klaus

There's no way how a correct functioning I2C master or slave could pull SCL high. Either the differential buffer on the slave side or LTC4015 isn't working correctly.

Hi,

Unfortunately there are some I2C master implementions - without clock stretching capability - that drive SCL HIGH. I don´t recommend to use this.

But here it seems it´s from the slave side, which is never allowed (afaik).

Thus I assume something else is wrong here.
* Maybe latchup by exceeding the input voltage range. (no good GND connection between master and slave, no overvoltage / undervoltage protection?)
* Bad / noisy power supply on VDDA /VDDB,
* erronously driven EN pin
* ...

Klaus

Hi,

Sorry for wrong statement. Slave is not holding SCL line to high. Due to pull up resistor SCL goes to higher level.

Now we did I2C recovery testing as recommended above, but still facing SCL and SDA line latchup issue on slave side.

- - - Updated - - -

KlausST said:

Hi,

Unfortunately there are some I2C master implementions - without clock stretching capability - that drive SCL HIGH. I don´t recommend to use this.

But here it seems it´s from the slave side, which is never allowed (afaik).

Thus I assume something else is wrong here.
* Maybe latchup by exceeding the input voltage range. (no good GND connection between master and slave, no overvoltage / undervoltage protection?)
* Bad / noisy power supply on VDDA /VDDB,
* erronously driven EN pin
* ...

Klaus

Click to expand...

I will check above input and update you

KlausST said:

Hi,

Unfortunately there are some I2C master implementions - without clock stretching capability - that drive SCL HIGH. I don´t recommend to use this.

But here it seems it´s from the slave side, which is never allowed (afaik).

Thus I assume something else is wrong here.
* Maybe latchup by exceeding the input voltage range. (no good GND connection between master and slave, no overvoltage / undervoltage protection?)
* Bad / noisy power supply on VDDA /VDDB,
* erronously driven EN pin
* ...

Klaus

Click to expand...

If this is an issue, when we resetting I2C transreceiver supply voltage (VDDA/VDDB supply), I2C transreceiver should reset correct ?

But when we resetting Slave device supply voltage only issue is resolving.