I2C-SCL staying LOW on i.MX6

[alexungerer]

Hello,

We are using an I2C communication path on an i.MX6 Solo, via the i2c2 module.

It is a single master (i.MX6), single device topology, with a rate of 100 kbit/s. Communication consists mainly in reading the content of an EEPROM, reading the state of a few IOs, and sometimes program some IOs. Software environment is Yocto Dizzy.

For various reasons, it is important that SCL conforms to the I2C standard in that it remains in the HIGH state when not toggling.

But it appears that i.MX6's I2C leaves SCL LOW between some 8-bit words, sometimes for a time as long as several hundreds of microseconds.

Here is my question:

Is this a known behaviour? Is there a way of making sure that SCL never stays LOW within a data transfer?

Thank you for your help,

   Alex

[Pavel]

If the I2Cx_I2CR[MSTA] bit is cleared, the i.MX6 I2C master generates signal Stop on the I2C bus.

The I2C Specification contains the following:

Set-up time for STOP condition for Standard-MODE is minimum 4uS.

The i.MX6 Reference Manual contains the following about the I2C signal Stop:

A data transfer ends when the master signals a Stop, which can occur after all data is sent.

For a master receiver to terminate a data transfer, it must inform the slave transmitter by not acknowledging the last data byte. This is done by setting the transmit acknowledge bit (I2C_I2CR[TXAK]) before reading the next-to-last byte. Before the last byte is read, a Stop signal must be generated.

What delay happens on your board?

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[alexungerer]

Hi Pavel,

I don't think this behaviour is Stop-related, because it happens in the middle of a long read transfer. At that point the master receiver (iMX6) should not insert a Stop, because there are a lot more bytes to read.

I include a view of a transfer with a pause lasting 9.85ms between one byte read and the next (probably caused by some iMX6 peripheral arbitration?). This would be OK for us if SCL stayed HIGH during the pause...

Regards,

   Alex