Searching \ for 'I2C error handling' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'I2C error handling'.

Truncated match.
PICList Thread
'I2C error handling'
1999\08\06@091410 by Barry King


I'm using PICs as master and slave on I2C, too.  (two 16C76s)

It all works fine for most cases.

There is one error recovery case in the Slave's code that I am having
trouble solving.

When in Slave transmit mode, (that is, the Master is doing a read
from the slave) it is possible (for example becuase of
noise) for the NACK bit which flags the last requested byte
to be mis-read as an ACK by the slave.  If it is, the Slave hardware
will continue in transmit mode, and stretch SCL low waiting for the
next byte to be loaded.

The Master wants to STOP, but can't because SCL is locked low.  The
bus is hung forever.

Do you detect this failure mode?  How?  I think I'll get
another transmit complete interrupt, rather than the expected

What is the best way to get out of it?  Right now, I send a dummy
0xFF byte, figuring that that will release SCL and SDA and let the
Master STOP the bus.  Have you found a better way?

Another fine point: In slave receive mode, do you always get two
interrupts for the last byte and the STOP, or do you always get one
last interrupt with both bits (BF and P ) set?  Does it depend on
interrupt latency maybe?  I seem to be getting inconsistant results
on this, at this point I think I have to structure the ISR to handle
either or both in any one interrupt.

Thanks in advance for any insight you can lend; Of course I'm more
than willing to share anything I've found out that may help you.


Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...