MK22 master handling i2c clock stretching

Showing results for 
Show  only  | Search instead for 
Did you mean: 

MK22 master handling i2c clock stretching

Contributor I

Dear NXP Support,

We're using MK22FX512AVLQ12 in an application that is communicating over i2c to a bunch of slave devices and we think the i2c hardware isn't waiting long enough for the slave's clock stretching.  We see this effect on the bus where the master releases the lines and the slave holds the data line low longer than expected preventing the stop condition from being observed on the bus. 

Here is an excerpt from pg 40 of the TPS65988 datasheet discussing it's clock stretching.  ( I2C Clock Stretching

The TPS65988 features clock stretching for the I2C protocol. The TPS65988 slave I2C port may hold the clock line (SCL) low after receiving (or sending) a byte, indicating that it is not yet ready to process more data. The master communicating with the slave must not finish the transmission of the current bit and must wait until the clock line actually goes high. When the slave is clock stretching, the clock line remains low.

The master must wait until it observes the clock line transitioning high plus an additional minimum time (4 μs for standard 100 kbps I2C) before pulling the clock low again.

Any clock pulse may be stretched but typically it is the interval before or after the acknowledgment bit. 

In our case, the problem seems to be that the slave is stretching the clock after the ack bit, and what we see on the scope is that the data line rises before the clock is released, and then the stop condition doesn't appear on the bus.

In our transmit interrupt we're immediately clearing the IICIF interrupt.  During our investigation we've seen that the bus is still busy when we should be asserting the stop condition.  We want to know, does the i2c peripheral handle clock stretching after the ACK bit?  

0 Kudos
1 Reply

NXP TechSupport
NXP TechSupport

Hello @agillon,

Could you please share a picture of the behavior? Have you tried using our examples with the addition of the clock stretching? Is the same behavior happening? Also, if possible, could you please try using another slave?

For more information about the I2C, please refer to the following:

Best regards, Raul.

0 Kudos