• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 81 subscribers
  • Views 292 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Do I need to test for I2C stuck pin?

Cool Javelin
Expert 1680 points

I am writing code to communicate with another processor via I2C using a Piccolo u Controller.

The other processor is a slave to the Piccolo, in that during boot up, I use a GPIO line to reset the other then I setup the Piccolo I2C to match the others default.

Normally, the 2 lines, I2Cclk and I2Cdata, are both hi with pull up resistors and in production I don't anticipate issues, but...

During debug (especially debugging the I2C with single step,) I may interrupt the Piccolo in the middle of a data byte, and the other may be holding the data or clock line lo till it finishes the byte.

I was in the middle of writing a routine to "test for stuck lines" and handle accordingly, but I got to thinking I may be doing an overkill.

Does anyone think this going to be an issue?

Thanks, Mark.

  • 0
    TI__Expert 8950 points

    If you want to release the I2C bus, the usual procedure is to reset everything connected to it. Piccolo MCUs set all GPIOs to input mode on reset.


    One thing you can do for debug is set the I2CMDR.FREE bit. This will allow the I2C module to finish transferring data even when the debugger halts the CPU. Note that you still have to set I2CMDR.STP to release the clock.

  • 0 in reply to Adam Haun
    Expert 1680 points

    Hi Adam:

    Thanks for the reply, and the tip about I2CMDR.STP. I overlooked that.

    I  think all will be good now.

    Mark.