Is STM32 hardware I2C a pitfall ?, Stm32 hardware i2c

Is STM32 hardware I2C a pitfall ?, Stm32 hardware i2c

/**

**************************************** **************************************

* @ Author Maoxiao Hu

* @ Version V1.0.0

* @ Date May-2015

**************************************** **************************************

* <COPYRIGHT 2015 ISE of shandong university>

**************************************** **************************************

**/

I have been debugging the hardware I2C of STM32 for a long time, and I have searched almost all the information. I will do a thorough research on whether it can work normally.

 

The following are some conclusions I have drawn during the test:

1. the CLK of the hardware I2C works at 50 kHz or below, and there will be no cards under any circumstances. (My testing time is 20 h)

2. the CLK of hardware I2C works at 99% kHz and kHz, and gets stuck within 1 hour at probability, or even dozens of seconds.

3. the CLK of hardware I2C works at any frequency. When reading or sending data, it is absolutely not allowed to interrupt other interrupt events. Otherwise, it will be stuck, but it is only a matter of time.

To sum up, the stable operation of hardware I2C is: working at 50 kHz or below, and ensuring that there is no other interruption to interrupt its work. This method is only applicable to scenarios with low speed requirements, such as EEPROM reading. However, high-speed devices, such as AD chips of some models, cannot be used.

 

If you need a high speed (400 KHz), we recommend that you use the alternative solution GD32 of STM32, which is fully compatible with STM32 but solves the hardware I2C bug of STM32, after my actual test, I worked at KHz without any errors within 48 hours. However, we still need to note that external interruptions cannot interrupt I2C.

 

For the interruption recommended by ST to work on DMA and highest priority, I can only say that you can use I2C based on your own situation, because if you use ucos ii or other real-time operating systems, this method of setting the highest priority is not recommended. If you are a bare-metal program with a small number of tasks, you can consider this DMA + interrupt method. Otherwise, problems may occur, but the test duration is a problem.

 

Note the following:

(1) The above only takes into account the purest hardware I2C Code. For some methods that use software to make up for, for example, setting timed-out exit in a frequently stuck part is not covered in this article, this has damaged the normal I2C protocol.

(2) because the high-level realm of using STM32 is the use of interrupted scheduling tasks rather than endless loops, and hardware I2C is very taboo for interrupt interruption, as your programming and understanding of the operating system improves, you will feel that the STM32 hardware I2C is a pitfall.

 

Therefore, the hardware I2C of STM32 is indeed a pitfall and the environment requirements for normal operation are very demanding. Therefore, I have switched to using the GD32 chip.