We use the I2C peripheral of the STM32H755ZI MCU. We operate the I2C in master mode and normally everything works perfectly.
However, sometimes the SCL line is kept low for bit longer during an I2C read operation, using the HAL function "HAL_I2C_Master_Receive(...)", see red box in the image below. The master (STM32H7) is supposed to send its ACK bit but it waits a bit longer than the previous ACKs.
According to the reference manual (RM0399) in chapter 50.4.7 - Data transfer and Figure 586, the I2C master is allowed to strecht its SCL line as long as the RXNE bit is equal to 1, because the previous received data is not yet read from the RXDR register. This explains the above behaviour of the longer low periode of the SCL line.
Now we have the problem that in some I2C read operations the master does not send its ACK bit and holds the SCL line low until the CPU is reset (see image below). As a consequence, all subsequent I2C operations (read or write) are not possible and the HAL driver reports a busy I2C bus. Only after a CPU reset the lines are released to idle state again.
As described above, the only reason to keep the SCL line low (after receiving a complete byte) is if the RXNE bit is still set. On the other side the HAL function "I2C_WaitOnRXNEFlagUntilTimeout(...)", which is called by "HAL_I2C_Master_Receive(...)", returns HAL_Error because of a timeout (1 ms) as it is waiting for the RXNE bit to be set.
This are two contraticting informations. The SCL line remains low as it waits for the RXNE to be reset (=0). The HAL driver runs into an timeout error as it waits for the RXNE to be set.
Moreover, none of the error bits in the ISR register are set when the timeout error is returned.
Why does the I2C master not send its ACK bit in this situation?
Any help is appreciated.