Posted on May 17, 2016 at 11:19When enable I2C3, CubeMX will generate stm32f4xx_hal_msp.c with a function named HAL_I2C_MspInit(), and in that function, the code will first config PC9 and then PA8 to be I2C pins. This order may lead to a busy state for I2C3.
This problem may occur when turned the pins to norm gpio to handle bus error.
In my code, if the bus stuck in busy state, pins will be changed to norm GPIO will PP output to generate signal manually and make the bus back into normal state. This is fun with I2C1 and I2C2, but when I use I2C3, because the order for I2C1 and I2C2 in HAL_I2C_MspInit() is SCL first , but for I2C3, it's SDA first, the problem will occur, and the bus will again goto busy state
