Hello Viresh, On Mon, Nov 26, 2012 at 06:21:25PM +0530, Viresh Kumar wrote: > On 26 November 2012 17:15, Paul Carpenter > <paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Unless you know why the bus is stuck, how can you reset reminder this > > method ONLY works if SCL is high and SDA probably was low and the slave > > device is what is stuck in wrong state. NOTE SCL and SDA high can be > > considered as BUS IDLE or having passed SDA = 1 waiting next clock edge > > or state transition without other state information. > > > > From i2c protocol Rev. 03 section 3.1.16 titled "Bus clear" first bit - > > > > "In the unlikely event where the clock (SCL) is stuck LOW, the > > preferential procedure is to reset the bus using the HW reset signal > > if your I2C devices have HW reset inputs. If the I2C devices do not > > have HW reset inputs, cycle power to the devices to activate the > > mandatory internal Power-On Reset (POR) circuit." > > > > So if you do not check that SCL is NOT stuck Low the rest will just do > > nothing, it wont clear the bus and the fault will not be reported. > > The open drain nature of the bus means that you may attempt to toggle it > > but if SCL is stuck low nothing will happen on the bus. > > > > Attempting to configure an SCL drive as any form of high driving output > > will create a situation that when the SCL is driven high a high driver > > on the GPIO will be driving into a stuck low situation potentially > > creating a short between a power source and a power sink, that in most > > cases will damage or shorten life of one or both ends. > > > > In over 10 years of using I2C in various forms the only times I have > > seen bus stuck or device in wrong state > > > > 1/ Some code changed a bus switch when Bus was NOT idle > > i.e mid transaction not sure what you mean here. Does it include a (SoC i.e. i2c master) reset while the bus is not idle? That's the problem I was faced with some time ago. > > 2/ Bit-banged I2C software was wrong incomplete transaction > > 3/ Short on bus > > 4/ Faulty device > > 5/ Faulty design so 1 and 0 thresholds were compromised I can add: 6/ device does clock stretching which is not detected/supported by the bus master 7/ clock frequency too high for a device In reply to a more detailed problem report that should be addressed by this series on spear-devel I asked a few questions to rule out 6/ and 7/. I cannot find it in an public accessible archive though. It's about a sta529 codec. When switching sample rates the codec then holds down SDA. After an additional clock pulse the device and bus are OK again. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
