Uwe Kleine-König wrote:
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.
....
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.
In this case the I2C master was in an ASIC undergoing manufacturing test
and the system controlling the tests and monitoring results had an
EEPROM and EEPROM emulator only one could be switched in at any time.
At current production rates the particular EEPROM will run out of
allowable write cycles in a day and become unreliable for calibrated
test system. Hence the EEPROM emulator, manufacturer wanted to be able
to switch the i2c bus in use but did not synchronise the switching to
bus idle so two devices would lock up, one the EEPROM halfway through
transaction and the emulator because it got out of sync garbage.
Despite the FPGA having the software programmable functions to switch
correctly, they were not used.
Anything more than that and "I would have to shoot you afterwards" :-)
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
Yep those can happen as well but I tend to deal mainly with embedded
systems so all clock speeds and clock stretching are none before hand.
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.
I mainly see clock stretching issues, but try to design them out by
different devices or controllers.
Best regards
Uwe
--
Paul Carpenter | paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
--
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
