Forums

I2C Question

Started by Anonymous March 18, 2006
If a I2C master is in the middle of communications transfer with a slave and the slave suddenly resets or hangs, how can the I2C master regain control of the bus, and how can it prevent from 'hanging' when the slave keeps clock stretching?


-=-
This message was sent via two or more anonymous remailing services.




Anonymous wrote:
> If a I2C master is in the middle of communications transfer with a slave and the slave suddenly resets or hangs, how can the I2C master regain control of the bus, and how can it prevent from 'hanging' when the slave keeps clock stretching?
If that is really how the slave fails, then no, it cannot recover. It is common to clock a i2c BUS many times, as a recovery scheme to encourage a Slave OUT of ACK, or Stretch modes, but that assumes the slave has some remnant ability. You will often see, these days, i2c slave devices with RESET pins - I suspect it is this type of issue that is driving that feature, as well as having a clean. known start state. There are also i2c MUX chips, so you can isolate stubs.... -jg
Jim Granville wrote:
> Anonymous wrote: > >> If a I2C master is in the middle of communications transfer with a >> slave and the slave suddenly resets or hangs, how can the I2C master >> regain control of the bus, and how can it prevent from 'hanging' when >> the slave keeps clock stretching? > > > If that is really how the slave fails, then no, it cannot recover. > > It is common to clock a i2c BUS many times, as a recovery scheme to > encourage a Slave OUT of ACK, or Stretch modes, but that assumes the > slave has some remnant ability. > > You will often see, these days, i2c slave devices with RESET pins - > I suspect it is this type of issue that is driving that feature, > as well as having a clean. known start state. > There are also i2c MUX chips, so you can isolate stubs....
After having a problem in a product where a reset in happened in the middle of an I2C transfer causing the slave device to think that it was still in the middle of an I2C transfer. We implemented a reset routine and the following is a comment from that routine that describes the process. Essentially, at re-boot, we clock the I2C bus up to 9 times until the SDA line goes HIGH. While this may not be your problem, perhaps it will give some help to others. // If a confused slave device thinks that a // transaction is still in progress since the // last system reboot then it may be pulling // the SDA line LOW. // // If the slave believes that it is still being // read by the master, then it will drive the // bus with data for eight bit slots, and then // release the bus during the ACK bit slot. // // If a slave believes that it is still being // written by the master, then it will listen // (not drive the bus) for eight bit slots and // drive the bus LOW during the ACK bit slot. // // In order for the master to generate an I2C // Start Condition, both the SDA and SCL lines // MUST be HIGH (not driven LOW) by any slaves // (or anything else.) // // Since we have already determined that the // SCL line is OK, we now clock the I2C bus // up to 9 bit time slots (the time it takes to transfer // a single byte plus the ACK). // // Once we reach a point where the SDA line is // HIGH, we are done. // // If the SDA line never goes HIGH within these // nine bit slots, then we have a component or // circuit-board failure. Sorry for any incoherence ... I'm a bit tired ;-) -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
In article <441cc80e$1@clear.net.nz>, no.spam@designtools.co.nz says...
> Anonymous wrote: > > If a I2C master is in the middle of communications transfer with a slave and the slave suddenly resets or hangs, how can the I2C master regain control of the bus, and how can it prevent from 'hanging' when the slave keeps clock stretching? > > If that is really how the slave fails, then no, it cannot recover. > > It is common to clock a i2c BUS many times, as a recovery scheme to > encourage a Slave OUT of ACK, or Stretch modes, but that assumes the > slave has some remnant ability. > > You will often see, these days, i2c slave devices with RESET pins - > I suspect it is this type of issue that is driving that feature, > as well as having a clean. known start state. > There are also i2c MUX chips, so you can isolate stubs.... > > > -jg >
I have used a switched power scheme in the past to do a cold boot on I2C devices if, for one reason or another, they time out during a transfer. I2C device times out, make sure your I2C pins are in high impedance mode, kill the device power, try again, after N retries, the device must be fried, do something meaningful with that info. Jim