thanks a lot for your quickly reply. At the moment the only solution that I have found for this problem is improve the routine with some timeouts and retry it if unsuccesfully after a complete re-initialization of the I2C bus. In this manner the mistake seems to be OK. Best regards, Stefano
I can confirm your problem. Since the very first version of the firmware library we tried I2C to access several devices (EEPROM, LM92, ...) and discovered that at some point the I2C always gets stuck. Most of the time this happens while sending the start condition when the expected event is not fired. Over the time, ST improved the firmware library and the stuck-error appeared less often. Nevertheless the error still occurs, especially after a longer uptime of the device. When looking at the I2C bus using a scope everything looks fine so I guess the STM32 has an internal problem. Because the problem was not resolved over a long time (you can see that when you search in the forum) we replaced most of our I2C devices with SPI devices. You can take a look at the MIOS32 source code if you still want to use I2C. Their implementation is the best I have seen so far: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2FSTM32F10x%2Fmios32_iic.c
We too am facing the same problem as you do. We are using STM32F103R8 controller.
We tried to do timeouts and then reset the I2C bus, but that does not help it recover. We first thought it was the slave not responding but it took us a lot of time to find that the controller is the culprit. We see that the I2C is stuck up in the while loop waiting for the ack from the slave after sending the slave address on the bus.
Could you please tell us if you have found a soultion to this I2C stuck issue.
