AnsweredAssumed Answered

K64 I2C Dead Lock handling with KDS 2.0

Question asked by peterprocek on Nov 20, 2017
Latest reply on Nov 24, 2017 by Don Elmore

Hi all,

 

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:

 

https://www.nxp.com/docs/en/application-note/AN4803.pdf 

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?

 

Thank you!

Outcomes