I2C hangup

Not personally, but you'll find some application notes on Phillip's web site where they discuss the problem and propose various solutions. They make "bus splitter" ICs that can be used to isolate "hung" portions of the bus, generate error signals that can be used to reset processors, etc.

Part of the trick, though, is deciding how long SDA should be able to camp low before you decide the bus is hung. I've heard of people sometimes using SDA as a form of handshaking and allowing up to ten seconds before they time out the bus!

---Joel

Not me; I always use SPI.

John

At last, a friend.........................................

martin

Following solution is recommended by Atmel in the AT24C01 memory datasheet:

MEMORY RESET: After an interruption in protocol, power loss or system reset, any 2-wire part can be reset by following these steps:

1. Clock up to 9 cycles.
2. Look for SDA high in each cycle while SCL is high.
3. Create a start condition.

Perhaps this would help.

Best regards

Piotr

I mentioned this problem in a thread on hot swap systems. I've done systems with dozens of I2C endpoints, and the solution was to use a SMBus controller.

I2C is specified to DC, whereas SMBus (same bus protocol) is not, and therefore implements a timeout. Note that provided the bus master implements the SMBus timeout, you'll be ok. It gets more complicated if you have multiple masters, but the principle is the same.

I never use pure I2C now simply because of this issue. Most processors with internal I2C can implement the timeout (using internal timers).

Cheers

PeteS

First came across this when reading 24C64's.

We''ve also seen the same lockup where we share an I2C LCD display driver between 2 micro's, and the user rather crudly has a switch between micro A and micro B.

The fix in both cases was as Piotr suggested, if bus is at fault, cycle the clock up to 9 times stopping when SDA goes high, then the bus is recovered.

Regards Alec

I did find a bug in the Cypress I2C code which resulted in this. Fix is trivial, just stop the I2C when you see NACK:

void i2c_isr(void) interrupt I2C_VECT { // I2C State Machine if(I2CS & bmBERR) { I2CPckt.status = I2C_BERROR; } else if ((!(I2CS & bmACK)) && (I2CPckt.status != I2C_RECEIVING)) { I2CPckt.status = I2C_NACK; I2CS |= bmSTOP; // RWD 8 June, 2005 } else ...

Of course, not the whole solution, but every little helps.

Bill

This is usually a deadlock, caused by improper master control of the bus. Usually, the slave is waiting for you to clock something, and you are waiting for the slave to do something. If, for example, you forget to NACK the last read, you can get stuck in a state in which the slave thinks it's still talking.

If this is happening, clocking the bus will eventually cause the slave to release SDA, because it wants to see your ack after 8 bits. If you leave SDA alone, it'll think it's a nack, and stop trying to write data to you.

If the slave is holding SCL low, you are probably screwed.

If the slave devices have a reset, use that instead of power. The FET thing makes sense if there isn't a reset pin. Note that if the device doesn't take too much power, you can just run it off of the microcontroller pin. I believe PICs have a limit of 20mA, which may be fine. I've done this with LCD displays before with no problem.