• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 728 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/EK-TM4C1294XL: I2C failure edge case

Adam Parker
Intellectual 680 points
Part Number: EK-TM4C1294XL

Tool/software: TI-RTOS

I'm working on some firmware that coalesces data from several I2C sources and moves it up to the cloud.  What I have noticed is when I2C is used in blocking mode if the device fails to respond the firmware blocks forever.  I consider this poor behavior as I would rather execution continue, the failure marked and relayed to the user.  I've also noticed that I2C does not seem to have a timeout mechanism.  I very well could be wrong on these facts, correct me if I am.

My halfway workable solution assuming the above is to do I2C in callback mode.  If callbacks fail to happen in a certain time, sound the alarms.  However I am led to wonder how to recover from this.  My best guess is close the driver and restart it but I'm not sure what happens to pending operations on close.  Can anyone shed some light on what memory might still be active or if this is a safe operation?  If I can kill the driver, mark that chip as dead and restart the driver polling the rest I can recover to a hobbled state.

In callback I guess it's not paramount that the I2C driver be able to recover without a power reset.  When it dies, I could just let it stay dead but I'm looking for all my options.

Thanks for your help

  • 0
    TI__Guru* 96960 points
    Hi Adam,

    We've had multiple requests to add a timeout value for I2C, but unfortunately it never makes the cut to get into a release. The work-around is to use Callback mode (as you noted). If you detect a problem, you should close the corresponding I2C instance via the I2C_close API.

    Todd
  • 0 in reply to ToddMullanix
    Guru 117855 points

    If I may - sometimes the "attached Slave proves the cause or is victimized" by a failed I2C transaction.

    In recognition of this - we often employ a GPIO to "power" the Slave - which insures the Slave's "return" to initial state upon GPIO toggle.     (a small FET may provide power beyond the GPIO's capability)  

    It is also possible to generate multiple SCL clocks to recover a Slave - yet should that fail - power toggle (always) works...      A "free" MCU Timer may perform the "time-out" detection - and launch each level of recovery - as required...