I2C Bus Recovery Question

[dpaul]

Greetings:

After much anguish, I have managed to pull together I2C code to handle multi-byte Master transmitter to Slave receiver messages (no big deal) AND multi-byte Slave transmitter to Master receiver (which was not at all obvious).

Error recovery at the Master receiver, however, is causing me no end of additional problems, and this is where I could use some sage advice.

I my Master receiver code, I, of course, start out with a address I2C_Write() with the address LSB set, then make successive calls to I2C_Read(Ack) until the very last byte to be read, with is retrieved with a call to I2C_Read(NoAck). This works very well until you test the code by halting the Slave transmitter from sending all the expected bytes, that is, I make a call to I2C_Read(Ack) for which there is no Slave response. Since the Ack is expected but does not occur, the I2C_Read(Ack) call locks up.

What is the proper method to reset the I2C bus in this case? I've read in a Philips publication hints of nine SCL cycles then clearing the SCL and SDA lines would behave as a reset, but I'm not quite sure how to implement this. I have tried to use a timer interrupt in which, if your not done I2Cing after an interval, you manually toggle the SCL/SDA lines, but I've had some curious timer interrupt behavior during I2C operations, which may be part of I2C or a whole other problem. Anyway, this seems extraordinarily brute force, such that I would hope there would be a more elegant solution. Are there any thoughts or suggestions from the I2C community?

Thanks,
Doug

[Ttelmah]

If you are using the hardware I2C, look at I2C_POLL.
The 'clear' behaviour will depend on how your slave behaves. Normally a repeated I2C_START, will start a new transaction, but if the code has hung in the slave, it will be down to you having to recover from this (watchdog is perhaps the normal recovery option).

Best Wishes

[Mark]

When you make the I2C_Read(Ack) that locks up the system, how are you halting the slave? The slave is probably holding the clock line low (stretching). CCS probably doesn't handle this very well. That is why I tend to shy away from their built in functions. You don't have control over them!