[lm-sensors] i2cdetect running slow but not "bus inactive" slow, not sure why?

[Wayne Tams]

Hi,

i2cdetect is behaving in a fashion that I have not seen before and I
just would like to know if anyone has a suggestion on what it is
telling me.

Normally i2cdetect returns in <1s, if the bus were inactive it would
take closer to 20s. However I'm finding that the scanning is taken a
round 5s and the addresses returned appear random, except for one.
Obviously there must be a fault in my hardware, but I just wanted to
make sure that was/wasn't a common explanation for this behaviour
before I go debugging up the wrong tree.

Thanks

Wayne

[Guenter Roeck]

Post by Wayne Tams
Hi,
i2cdetect is behaving in a fashion that I have not seen before and I
just would like to know if anyone has a suggestion on what it is
telling me.
Normally i2cdetect returns in <1s, if the bus were inactive it would
take closer to 20s. However I'm finding that the scanning is taken a
round 5s and the addresses returned appear random, except for one.
Obviously there must be a fault in my hardware, but I just wanted to
make sure that was/wasn't a common explanation for this behaviour
before I go debugging up the wrong tree.

I typically see this kind of problem if there is something wrong on the
i2c bus, for example if a signal is pulled high or low. I have also seen
it after I managed to physically "destroy" an I2C controller by applying
a reversed voltage to the i2c signal pins.

If you have a logic analyzer or a scope, you might want to connect it to
the clock and data lines to see what is happening on the bus.

Guenter

[Wayne Tams]

Hi Guenter,

Turns out it was an I2C voltage translator had popped, thankfully all
my I2C devices are ok. Did not realise i2cdetect could behave in such
a peculiar way.

Thanks

Wayne

On Fri, Dec 16, 2011 at 4:29 PM, Guenter Roeck

Post by Guenter Roeck

Post by Wayne Tams
Hi,
i2cdetect is behaving in a fashion that I have not seen before and I
just would like to know if anyone has a suggestion on what it is
telling me.
Normally i2cdetect returns in <1s, if the bus were inactive it would
take closer to 20s. However I'm finding that the scanning is taken a
round 5s and the addresses returned appear random, except for one.
Obviously there must be a fault in my hardware, but I just wanted to
make sure that was/wasn't a common explanation for this behaviour
before I go debugging up the wrong tree.

I typically see this kind of problem if there is something wrong on the
i2c bus, for example if a signal is pulled high or low. I have also seen
it after I managed to physically "destroy" an I2C controller by applying
a reversed voltage to the i2c signal pins.
If you have a logic analyzer or a scope, you might want to connect it to
the clock and data lines to see what is happening on the bus.
Guenter

[Guenter Roeck]

Post by Wayne Tams
Hi Guenter,
Turns out it was an I2C voltage translator had popped, thankfully all
my I2C devices are ok. Did not realise i2cdetect could behave in such
a peculiar way.

Hi Wayne,

please don't top-post.

Nothing to do with i2cdetect, but with the i2c bus driver. i2cdetect tries to read,
and the bus driver ends up getting a transfer timeout for each read. Depending on
the I2C bus chip and the driver, timeouts can be _very_ long, up to 500ms per read
or even more.

Guenter

Post by Wayne Tams
Thanks
Wayne
On Fri, Dec 16, 2011 at 4:29 PM, Guenter Roeck

Post by Guenter Roeck

Post by Wayne Tams
Hi,
i2cdetect is behaving in a fashion that I have not seen before and I
just would like to know if anyone has a suggestion on what it is
telling me.
Normally i2cdetect returns in <1s, if the bus were inactive it would
take closer to 20s. However I'm finding that the scanning is taken a
round 5s and the addresses returned appear random, except for one.
Obviously there must be a fault in my hardware, but I just wanted to
make sure that was/wasn't a common explanation for this behaviour
before I go debugging up the wrong tree.

I typically see this kind of problem if there is something wrong on the
i2c bus, for example if a signal is pulled high or low. I have also seen
it after I managed to physically "destroy" an I2C controller by applying
a reversed voltage to the i2c signal pins.
If you have a logic analyzer or a scope, you might want to connect it to
the clock and data lines to see what is happening on the bus.
Guenter

[Wayne Tams]

On Tue, Dec 20, 2011 at 4:18 PM, Guenter Roeck

Post by Guenter Roeck

Post by Wayne Tams
Hi Guenter,
Turns out it was an I2C voltage translator had popped, thankfully all
my I2C devices are ok. Did not realise i2cdetect could behave in such
a peculiar way.

Hi Wayne,
please don't top-post.

Sorry was not not thinking...end of the day

Post by Guenter Roeck
Nothing to do with i2cdetect, but with the i2c bus driver. i2cdetect tries to read,
and the bus driver ends up getting a transfer timeout for each read. Depending on
the I2C bus chip and the driver, timeouts can be _very_ long, up to 500ms per read
or even more.

I see, that makes sense. Once again thanks

Wayne

Post by Guenter Roeck
Guenter

Post by Wayne Tams
Thanks
Wayne
On Fri, Dec 16, 2011 at 4:29 PM, Guenter Roeck

Post by Guenter Roeck

Post by Wayne Tams
Hi,
i2cdetect is behaving in a fashion that I have not seen before and I
just would like to know if anyone has a suggestion on what it is
telling me.
Normally i2cdetect returns in <1s, if the bus were inactive it would
take closer to 20s. However I'm finding that the scanning is taken a
round 5s and the addresses returned appear random, except for one.
Obviously there must be a fault in my hardware, but I just wanted to
make sure that was/wasn't a common explanation for this behaviour
before I go debugging up the wrong tree.

I typically see this kind of problem if there is something wrong on the
i2c bus, for example if a signal is pulled high or low. I have also seen
it after I managed to physically "destroy" an I2C controller by applying
a reversed voltage to the i2c signal pins.
If you have a logic analyzer or a scope, you might want to connect it to
the clock and data lines to see what is happening on the bus.
Guenter