The FMPI2C master of STM32F446 module extends (stretches) the acknowledge (ACK) bit with random delays

[Dimalex]

The FMPI2C master of STM32F446 module extends the clock of the acknowledge bit with random delays from a few microseconds to a few milliseconds. That happens quite frequently w/o causing an issue, but sometimes the SCL line remains forced low by the master and the only way to continue the communication is to re-initialize the I2C module.

The application is bridge between I2C memory and USB interface.

The clock speed of I2C is 1Mhz. Polling is used instead of interrupts to control the I2C module.

HAL_FMPI2C_Mem_Read() function is use to read big amount of date from I2C EE memory.

Since FREE RTOS is used, probably it is causing this issue due to USB interrupts while the I2C module has to be acknowledged by the SW.

I looked at the errata sheet of the MCU, but nothing like that is mentioned. https://www.st.com/resource/en/errata_sheet/es0298-stm32f446xcxe-device-limitations-stmicroelectronics.pdf

Any idea what could be done here?

[TDK]

I2C will stretch the clock if information is not available to the peripheral in time. At 1 MHz, I imagine the code isn't fast enough to keep up with the stream, especially if RTOS is used. Clock stretching in I2C is normal.

The I2C peripheral on the STM32F4 is a bit of a mess. I would not be surprised if there were race conditions present in the HAL code. If issues happen, you can pause and inspect registers and software state machines to try and debug.

[Dimalex]

Thanks for the reply.

I agree with everything what you said, but this case is about the ack bit which is set once in the begging of the read transfer and only changed at the last byte.

We'll try to debug it, once the project is migrated to CubeIDE.

[waclawek.jan]

> Since FREE RTOS is used,

OK so you've answered your question already.

Master receiver stretches the ACK bit until data are read from DR (that is to prevent overflow).

> Any idea what could be done here?

Use DMA to pull data from data register.

> sometimes the SCL line remains forced low by the master and the

> only way to continue the communication is to re-initialize the I2C module.

I don't have experience with FMPI2C, but the "classic" I2C module is prone to hang in noisy environment. Increase "signal hygiene" (including grounds!), implement timeouts.

JW

[Dimalex]

Indeed DMA shall be used to avoid such "issues"

So, the hanging situation might not be related with the stretched ACK, but with the signal hygiene? In this case only thing we could do is to implement retries and workarounds.