If an i2c_write() or i2c_read() fails?

MikeValencia · Joined: 04 Aug 2004 Posts: 238 Location: Chicago

If i'm in the middle of a sequence of i2c transactions (i.e. my initial i2c_start() went thru okay, etc.), and all of a sudden, a write() fails to get an ack, then what should I do?

1. issue a stop(), and retry the initial start() all over again from the first stage?

OR

2. Retry the failed write() a couple of times? (Eventually it ought to work?)

I've got an application out in the field where i'm scared that a "frozen" i2c bus will have bigger consequences.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

This appnote is about how to reset the i2c bus. See page 2:
www.analog.com/static/imported-files/application_notes/54305147357414AN686_0.pdf

In this appnote, read the paragraph near the bottom of page 2:
http://pdfserv.maxim-ic.com/en/an/AN476.pdf

This appnote has some code on page 15 which does i2c error recovery:
http://eecs.oregonstate.edu/~traylor/ece473/pdfs/I2C_usage_Phillips.pdf

-------
Edit: Fixed broken llinks

kender · Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley

I had an experience just like Mike had described: once ever so often the I2C transaction would start happily but then fail in the middle. It turned out that I was using the I2C bus both in the main() and in the interrupt. Yes, I know that serial communication in the interrupt is a no-no, but that was 400kbps I2C bus and I was making 1-byte writes to a DAC. Oddly enough, in the beginning the system was wprking just fine, because the main() was de-facto synchronized with the interrupt. But then I had changed something, and I started to get the bug i have described initially. So, the following thing was happening:
(1) main() would successfully initialize the I2C transaction.
(2) interrupt would occur, and it would re-initialize the I2C also successfully.
(3) interrupt would finish the transaction successfully. The bus is now stopped.
(4) after the interrupt main() would try to carry on with its transaction and fail.

Moral (at least for myself): All of the I2C transactions should be either in the main() or in the interrupt of the same priority.

MikeValencia · Joined: 04 Aug 2004 Posts: 238 Location: Chicago

Thanks PCM, i'll be reviewing those docs carefully.

And Kender, when you use 400kbps rates, what resistor values do you use?

Thanks,
Mike

kender · Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley

MikeValencia · Joined: 04 Aug 2004 Posts: 238 Location: Chicago

I stumbled across the LTC4304 by Linear Technology, which is an IC that can restore stuck i2c buses if the SDA or SCL is stuck for more than 30ms. It will clock SCL for a maximum of 16 times.

This is very similiar to PCM's first link above on how to reset an i2c bus. Looks like i have to keep an "i2c watchdog timer" to wait for the completion of a write or read, then manually clock SCL at most 9 times if the timer trips. If i'm using hardware i2c (MSSP), then i guess i'll have to disable the mssp temporarily and bitbang the pins. This is a much cheaper method than using the Linear IC.