I2C hangup

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I have noticed while checking out a prototype board that the I2C devices
occasionally hang the bus (SDA held low) preventing any further bus
transactions.  My only fix is to cycle power to the board.  That leads me to
wonder whether adding a fet power switch feeding the I2C devices controlled
by the micro might be of benefit - when the micro detects a hung bus, it can
"reset" the I2C devices.

Anyone ever have to do this?



Re: I2C hangup
Quoted text here. Click to load it


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



Re: I2C hangup

Quoted text here. Click to load it

Not me; I always use SPI.

John


Re: I2C hangup

Quoted text here. Click to load it

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


Re: I2C hangup
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


Re: I2C hangup
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


Re: I2C hangup
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

Quoted text here. Click to load it



Re: I2C hangup
Quoted text here. Click to load it

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.

--
Regards,
  Bob Monsen

We've slightly trimmed the long signature. Click to see the full one.

Site Timeline