The function HAL_I2C_Mem_Read_IT and HAL_I2C_Mem_Write_IT are blocking until the first ACK

[maximejavaux]

Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• Custom board with a F769
• STM32CubdeIDE STM32CubeF7 Firmware Package V1.16.2
• Using I2C with a device at any adress

Describe the bug Both the HAL_I2C_Mem_Read_IT and HAL_I2C_Mem_Write_IT functions are blocking during address send. The implementation does not use interrupt during this first step. The implementation is less efficient than the implementation in the F4 version that takes advantage of the interrupts. STM32CubeF4 Moreover, the behaviour is not equivalent as for the F4, we have an error callback if the slave at the specified address does not acknowledge whereas the F7 version does not have a callback and report by return of a HALL_ERROR for both the HAL_I2C_Mem_Read_IT and HAL_I2C_Mem_Write_IT functions.

How To Reproduce

1. Any board with a F7 and an I2C device

2. Communicate with the I2C device using interrupts mode in the F7.

3. Notice that both the HAL_I2C_Mem_Read_IT and HAL_I2C_Mem_Write_IT functions are blocking until the ACK bit.

Additional context Switch to an implementation such as the one of the F4 series which is more efficient

Screenshots If applicable, add screenshots to help explain your problem.

[HBOSTM]

Hello @maximejavaux

On my side there is no problem in the HAL driver, I created an example with STM32F769I EVAL using HAL_I2C_Mem_Read IT and HAL_I2C_Mem_Write IT, it works fine. So, Would you please give us more details about how you got this issue? And share the code you have used to reproduce this problem.

With regards,

[Gozem]

You don't need to test this. You can simply read the code and realize that the address for the memory we want to read/write is sent using polling. With a timeout of 25 ms.

Internally, the first thing that happens is I2C_RequestMemoryRead(). Which will run I2C_WaitOnTXISFlagUntilTimeout() using the timeout I2C_TIMEOUT_FLAG, which is 25.

Try sending something to an I2C-device that doesn't exist, i.e never ACKs. In theory, you should get blocked for 25 ms before it fails.

I have not tested this my self. I just noticed this bug in mail notices and we do also have problems from time to time with our I2C on STM32F769Ni. Never really pinpointed the problem.

[maximejavaux]

Yes, as @Gozem said: " the address for the memory we want to read/write is sent using polling. With a timeout of 25 ms." I would also add that the implementation is different than the one of the F4 series and is (to my mind) less efficient for the F7 series as the F4 is fully non-blocking where the F7 series is NOT fully-not blocking. Also: in consequence, the error handling is different. When a device is not responding at the target address, the F7 version will notify the error as a function return (with a HALL_ERROR) whereas the F4 version will go to the dedicated callback (HAL_I2C_ErrorCallback). Therefore, in addition to the less efficient behaviour, we need to handle the two series with a different coding strategy concerning error handling. To see the difference, just go to the code of the F4 and F7 series: https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_i2c.c https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2c.c

[HBOSTM]

Hello, @maximejavaux @Gozem

This issue has been fixed in the last version, I suggest you to migrate to F7 cube 1.17.0. Could you please try with this last cube and come back to me.

With Regards

[HBOSTM]

Hello @maximejavaux @Gozem

First of all, thank you for this contribution. If this problem is solved from your side, please allow me to close it.

Best Regards,

[Gozem]

I didn't open this ticket. I don't have the resources to verify this currently. I can only read the code.

[HBOSTM]

Hi @maximejavaux ,

Please allow me to close this issue. Thank you again for your comprehension.

With regards,