PCA9518: I2C failure on back to back read/write transactions

What is that issue?

Please show an oscilloscope trace of the signals on both sides of the hub.

Hello Shubham,

Our Apps team is current out of office because of a US holiday. Please expect delays in our response. Thank you for your understanding.

Regards,

Josh

Hi Shubham,

I agree with Clemens here. 

A scope capture would be helpful to understand how the I2C waveforms look before and after the hub. 

Regards,

Tyler

Hi Clemens & Tyler,

PFA of scope captures.

This is done for the periodic transaction.

Best Regards,

Shubham

Hi Shubham,

I am not noticing anything significant on the waveforms. 

What is the target device you are communicating with? 

Why choose a delay of 300ms? 

Does 1 ms work the same as 300ms between a write and read command? I am trying to understand if it is timing related. 

Regards,

Tyler

Hi Tyler,

The target device is a Lattice CPLD LCMXO3LF-9400C-5BG400CAK7.

We started trials with 1s and came down to 300ms with pass transactions, it fails at 200ms.

The status byte on master side (FPGA) shows BUS-hung | SCL-High | SDA Low, whenever we have a failure.

Also, we saw an errata for this part w.r.t Clock Stretching. Can this be any where related to our issue. 

Best Regards,

Shubham 

Hi Shubham,

Is there clock stretching when talking to the CPLD? 

The clock stretching errata is more associated with any device that uses rise-time accelerators in the system. Are there RTA's in your system? Devices such as TCA9416 / TCA9406 / TXS0102. 

The clock waveform looks okay, but can you zoom in on a single clock pulse to verify that it is clean? It looks like there might be more information to see on the rising edge. 

Regards,

Tyler

Hi Tyler,

There is no clock stretching when talking to the CPLD.

There are no RTA's in our system.

PFA of rise time captures at input and output side.

Best Regards,

Shubham

Hi Shubham,

The failure mode may be marginal. This overshoot type waveform on the rising edge may be causing a double clock edge which is causing issues. 

What are the pull-up resistors used on each I2C bus? 

Regards,

Tyler

Hi Tyler,

The effective pull-up on input side is 0.5k and on output is 4.7k.

Best Regards,

Shubham

Hi Tyler,

No we don't see any improvements.

It was 5k earlier but due to slow rise time we changed it to 0.5k.

Attaching the rise time snap with 5k Rpu.

Best Regards,

Shubham

Hi Shubham,

Shubham Srivastava said:

We started trials with 1s and came down to 300ms with pass transactions, it fails at 200ms.

The status byte on master side (FPGA) shows BUS-hung | SCL-High | SDA Low, whenever we have a failure.

What is the difference in timing of the I2C waveform between a pass transaction at 300ms, and a failing transaction at 200ms? 

I know SDA gets stuck low, but I assume the SCL clock frequency does not change between a 200ms and 300ms time between transactions. 

Help me to understand the differences between the two. 

Is there a scope capture of the bus getting stuck on SDA? 

It looks like the weaking of the pull-up resistor helped to reduce the non-monotonicity of the buffer output, which is what I expected would help to solve the issue. My theory is that this rising edge waveform of the PCA9518 would cause a false clock edge, where the target i2c device gets stuck because it sees a difference in the number of clock pulses sent. 

Regards,

Tyler

Hi Tyler,

The timing diagrams is not captured with different delay experiment. It was just a trial and error approach.

Yes, the SCL frequency is not changing.

We do not have a scope capture of the bus getting stuck on SDA.

The weaking of the pull-up resistor helped to reduce the rise time but the issue with i2c failure remains.

It is a 3.3V logic where, VIHmin for SCL/SDA is 0.7 x Vcc i.e. 2.3V. Can the step around around 0.7V cause the false clock edge. I'm not convinced.

Best Regards,

Shubham

Hi Shubham,

Any other target devices connected to the same side as the CPLD? 

How does communication with those target devices differ than the CPLD? 

Do you still run into lock up issues with SDA pulled low in those cases. 

If it is not a double clock related issue from the PCA9518, then it must be a target device pulling the bus to a stuck low condition. The PCA9518 is a buffer and only drives what it sees on the input. The PCA9518 cannot lock up the bus itself. 

Regards,

Tyler

Hi Tyler,

No other target devices connected to the same side as the CPLD. Even other channels 2,3,4 are disabled.

Best Regards,

Shubham

Hi Shubham,

I am running out of ideas why the PCA9518 itself would be the problem. 

Shubham Srivastava said:

We started trials with 1s and came down to 300ms with pass transactions, it fails at 200ms.

Looking back at our previous conversations, what changes are made to the I2C signal when operating at 1s intervals vs 200ms intervals? 

Is this a problem with the CPLD's ability to understand the I2C signal? 

I don't think we were able to capture the fail mode, i.e. SDA stuck bus issue, or a bit was flipped. 

Regards,

Tyler

Hi Tyler,

No changes were made to the I2C signal, when operating at 1s intervals vs 200ms intervals. It was a trial and error approach, started with 1s, reduced to 900ms.....on and on.....until 300ms it worked but failed at 200ms.

If this a problem with the CPLD's ability to understand the I2C signal, how to confirm this?

"I don't think we were able to capture the fail mode, i.e. SDA stuck bus issue, or a bit was flipped." -- SDA stuck was only read from the master's status register.

Best Regrads,

Shubham

Hi Shubham,

To know if the CPLD is holding the bus low, you can cycle the clock pin 9 times from the host controller. 

To know if the buffer in between the host and the CPLD is causing the data glitches, then if possible short across the buffer from host to CPLD to remove the influence from the buffer. Test again at different timings to see if the buffer was causing the issue in the first place. 

Regards,

Tyler

Hi Tyler,

The system is in transit from the manufacturing facility. We will try the suggested experiments once we receive them, it may take some time.

Best Regrads,

Shubham

Hi Shubham,

Please let me know the test results. Thanks. 

Regards,

Tyler