Currently I am running a FreeRTOS environment on the K64 in which I have a task setup to communicate with various I2C peripherals once a second. However, I've been noticing while debugging that when ever I do a software reset or re-flash my code, the I2C interface will more often than not return that it is busy on the very first instance of an I2C transaction after a reset. I feel like this is likely related to the possibility that the interface was reset before any stop or acknowledge conditions were met and the slave devices are in a dead-lock keeping the interface busy.
How do I handle the case of an I2C Dead lock scenario? I found the following application note regarding the topic:
Its a little dated, but it has software functions for I2C Recovery. It does not seem like the fsl_i2c.c driver handles recovery. There are flags that are set for a timeout but it does not seem to be used for anything.
I assume the approach would be that in all of my software which attempts an I2C transaction, I would need to poll if the interface is busy and do a manual count at which point a 'timeout' event would happen and the I2C interface would have to be reset by sending a couple of clock pulses followed by a stop signal.
Has anyone already encountered something similar to this/implemented this solution?