On Thursday 18 August 2011 21:51:52 Chris Jones wrote:
> On 17/08/2011 17:52, Paul Fidler wrote:
> > On Aug 17 2011, Wookey wrote:
> >> +++ Chris Jones [2011-08-17 13:31 +0100]:
> >>> Hello all,
> >>>
> >>> I know some people in the Balloon community have done a lot more
> >>> work with I2C than I have. I'm now using I2C more intensively and
> >>> having some problems. It works most of the time but will more or
> >>> less randomly give up and say, 'i2c-pxa: timeout waiting for bus
> >>> free'. Adding some debug to the i2c code shows that the PXA's I2C
> >>> controller is claiming to be busy at these times. Has anyone else
> >>> seen this?
> >>
> >> No, or at least not that I've noticed. My solar controller is using
> >> I2C down about 60cm of unshielded wire and has generally been
> >> reliable. It does sometimes jam up but I think that's at the 1-wire or
> >> OWFS level, not I2C, although it's hard to be sure.
> >> This is all with a very old kernel now (2.6.26 or so and OABI) so may
> >> not be directly relevant to current experience. PaulF is the real I2C
> >> expert.
> >
> > I wouldn't call myself an expert...
> > I have seen transient I2C errors, probably caused by spikes on the
> > bus, when using I2C to talk to a PIC that was driving a 12V DC
> > motor (via an L293). It was usually best to avoid turning the motor
> > from full on to full reverse as the next I2C message was then usually
> > missed.
> >
> > I don't actually recall whether I had that specific error ('i2c-pxa:
> > timeout waiting for bus free') although I may well have done. I have
> > seen a few 'timeout' style messages over the years, most of them
> > entirely due to dodgy soldering (usually my own). These errors were
> > generally due to shorts with either SDA or SCL to either high, low, or
> > each other. On one occasion the 'short' was actually the presence on the
> > bus of a PCF8574 which had been previously been fried by a student.
> > Removing it made everything work again...
>
> This is all very useful, thank you. I take that you both were using the
> CUED breakout board? If so, it contains a sneaky I2C buffer/protection
> arrangement which is supposed to make the bus more robust. That's
> different to what I'm working with, which is the raw bus from the PXA.
> Robustifying the electrical arrangements seems to be helping (thanks to
> Steve's hints off-list) but I am a bit concerned that the kernel can get
> its I2C driver so wedged as a result of a bit of an upset on the bus.
> It's an analogue world, after all.
Although this seems to be resolved-ish, I'll throw in an observation or two:
I2C will only work cleanly if the pull-up arrangement is good. Normally
pull-ups are a pretty random affair and resistors can be out a magnitude or
two and things will still work. Not so for I2C.
I2C has some pretty fussy rise time specifications and some chips and
controllers will throw a wobbly if the rise time is too slow. IIRC 1usec rise
times are required.
I did a slave I2C driver for an AVR about a year back. This was for use with
a Lego Mindstorms which uses I2C on the connections to the sensors and thus
has unshielded out-of-box cables up to approx 1m long. I had a lot of very
odd controller state transitions and often wondered how the hell it ever got
into those states. I suspect these were caused by poor rise times. Got there
in the end, but every transaction needed a reset to point the I2C controller
in the right direction again.
(text/plain)