• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 388 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.

TM4C1294NCPDT: Resetting an I2C Channel Similar to a Software Reset?

Terence Darwen
Intellectual 320 points
Part Number: TM4C1294NCPDT

Hi, we have a custom board that is hanging during I2C communication, it seems to randomly happen where both SCL and SDA remain high indefinitely and the I2CMCS register show both I2C_MC_BUS and I2C_MC_BUSBSY are set to 1.

We believe it's likely a hardware problem, and the hardware issue is currently under investigation, however, it would be nice to also somehow do a reset in software to fix the issue.

I've tried calling SysCtlPeripheralDisable(), then calling SysCtlDelay(2000) and then calling SysCtlPeripheralEnable() and reinitializing the I2C channel but that did not fix it.

I've also tried the following:

// Disable the I2C module
MAP_I2CMasterDisable(I2C9_BASE);

// Clear any pending interrupts
MAP_I2CMasterIntClear(I2C9_BASE);

// Re-enable the I2C module
MAP_I2CMasterEnable(I2C9_BASE)

That did not fix the problem either.

However, we've found that performing a software reset of the Tiva, by calling SysCtlReset(), does result in I2C communication on this channel to work again.

Is there some way to do what SysCtlReset() is doing, but only for a specific I2C channel?

  • 0
    TI__Guru**** 191256 points

    Hi Terence,

      Please try SysCtlPeripheralReset(). 

  • 0 in reply to Charles Tsai
    Intellectual 320 points

    Thank you .  We just tried SysCtlPeripheralReset(SYSCTL_PERIPH_I2C9) and no luck.  It did not have the same result as SysCtlReset().

    Question: After calling SysCtlPeripheralReset(SYSCTL_PERIPH_I2C9) should I reinitialize the I2C the same as I do at startup by calling SysCtlPeripheralEnable(), SysCtlPeripheralEnable(), GPIOPinConfigure(), MAP_I2CMasterInitExpClk(), etc or not?

  • +1 in reply to Terence Darwen
    TI__Guru**** 191256 points

    Hi Terence,

    Terence Darwen said:
    Question: After calling SysCtlPeripheralReset(SYSCTL_PERIPH_I2C9) should I reinitialize the I2C the same as I do at startup by calling SysCtlPeripheralEnable(), SysCtlPeripheralEnable(), GPIOPinConfigure(), MAP_I2CMasterInitExpClk(), etc or not?

    Yes, you need to reinitialize I2C but I'm not sure if this will fully resolve the problem if the slave is also in a hanging state. The reason is that the master has already lost synchronization with the slave for whatever reason. Earlier you mentioned, there could be some hardware issue. The slave could be in a unfinished (non-idle) state. For example, the slave may be expecting another clock from the master or it is expecting a STOP bit from the master. Therefore, not only you need to reinitialize the master but I think you should also reinitialize the slave to break it from a hanging state. 

    I thought in this post, Bob helped you for a similar issue and your problem was resolved. 

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/954162/tm4c1294ncpdt-problems-resetting-i2c-communication

  • 0 in reply to Charles Tsai
    Intellectual 320 points

    Hi Charles, thanks for the reply.  Reinitializing after calling SysCtlPeripheralReset() resulted in "fixing" the problem, or at least letting I2C communication continue.  Tho we still believe this is a hardware problem due to the fact that we've done SOOOOO much I2C communication the exactly same way with these same sensors on different boards and various other peripherals and never had this problem.

    Yes, the post you reference from a couple of years ago with Bob Crosby did cross my mind.  There are differences though: We were not seeing the I2C_MASTER_ERR_ARB_LOST error in this recent case.  Additionally, in this case the lines seem to be stuck high, which I didn't expect bit banging would fix.  I would expect bit banging to help in a case where the SDA was stuck low, but not stuck high like in this case.

    Anyway, we very much appreciate your help with this.  Thank you.