cancel
Showing results for 
Search instead for 
Did you mean: 

Missing I2C STOP condition

TDJ
Senior III

RM0394 (STM32L4..) in section 37.7.2 describing I2C_CR2.START bit states:

"setting this bit generates a START condition once the bus is free"

Section 37.4.8 reads:

"the master automatically sends the START condition followed by the slave address as soon as it detects that the bus is free (BUSY = 0) and after a delay of tBUF."

That sounds good. One may think that it is possible to queue in another transfer from HAL "transfer complete" event handler triggered by ISR.TXIS event. However, there seems to be a catch. In such case, even if CR2.AUTOEND bit is set, master does not set STOP condition before starting another transfer.

Single transfer properly ended with STOP condition.

I2C-STOP.png

Next transfer started from "transfer complete" event handler - STOP condition is missing.

I2C-NO-STOP.png

Is what I described above a proper and expected behavior? I have doubts.

However, when CR2.AUTOEND is disabled, ISR.TC event fires, and if from within this TC event handler I set both CR2.STOP and CR2.START bits, master correctly sets STOP condition and then starts a new transfer. Wow!

I2C-STOP-START.png

Tested with STM32L432.

Other I2C hardware problems that I described recently:

I2C, Incorrect PEC byte value after RESTART condition - hardware bug suspected

I2C master jams, unable to clear STOPF flag - probable hardware bug

3 REPLIES 3
S.Ma
Principal

I've used SW bit bang I2C master to bringup boards quickly with simple code.

Most I2C transactions don't need I2C clock stretch so the transaction duration can be <10 msec (short)

Always check SDA = SCL = HIGH before starting a transaction so you can put a breakpoint and some error recovery mecanism in place (RUGGED code which will run overnight and survive ESD, glitches)

TDJ
Senior III

"Most I2C transactions don't need I2C clock stretch"

@S.Ma​, Where from did you get this statistics and why does it matter? Any SMBus and practically any MPU-to-MPU I2C communication needs clock stretching, but what I described was not related to clock stretching.

Anyway, the truth is that ST I2C peripheral and its documentation copy-pasted from one resource manual to another with the same serious mistakes and omissions in my view is not exactly prime-time ready. It seems like that even ST engineers who wrote SMBus stack (AN4502) were not quite certain how to deal with it.

S.Ma
Principal

Let me precise my comment : Most non SW based true slaves do not support Clock Stretch. (SCL is a true input only, sensors, io expanders, etc..)

You are right when using multi-master mode, which is a less common configuration.