ISM330DHCX I2C issue

[ArnoutDekimo]

Hi,

I'm evaluating the ISM330DHCX by connecting it on a board with a linux device (imx8) through I2C. (using the st_lsm6dsx - (compatible = "st,ism330dhcx") device.

All of this seems to work out of the box, and I can read accelerations through IIO sysfs like so:

root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
218
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
226
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
222
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
1105
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
210
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
220
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
226

These values also nicely change with the actual orientation. But, like in the snippet above, every once in a while, even while the device is stationary, we get a totally unexpected reading - an outlier. (In this case the 1105)

I then further put a scope and logic analyzer to the signal at a very I2C clock low frequency (50kHz) to try and see if this data comes directly from the chip or not.

This is an example transaction where the data is read out:

Zoomed in point 1:

Reproduction of zoom point 1, but with scope and analyzer attached

Zoomed in point 2:

Reproduction of point 2:

Most of the time, we get something that looks like zoom 1. And sometimes, we get zoom 2 - in which case we see different data (especially in the most significant (last) byte.)

What's weird aside from the pattern changing, is that even in zoom 1 SDA is toggled for a very brief time (2us, while the clock period is 20us) before the clock starts. (Sometimes it also does this near the last cycle as well - but this seems to be more random)  The first glitch seems to happen every time when reading the data registers (0x28), but not for instance when reading register 0x10 .. when we also read out scenario (zoom) 1. In scenario 2 - the initial glitch is -not- there.

So, basically I am seeing the I2C signals clearly varying form time to time (scenario 1 to scenario 2), showing this sporadic higher value.

But in addition to that,  the data glitches bother me - and they do seem to be correlated with this behavior.

I took a longer trace, that corresponds to the salae output in attachment. 

Using the markers, you can clearly spot the different scenario's

root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
215
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
213
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
213
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
206
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
206
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
1123
root@dev:/sys/bus/iio/devices/iio:device1# cat in_accel_x_raw
201

SCEN1:

Scenario 2:

=> Does this ring any bell? Has anybody seen similar behavior when the chip responds to I2C readout?

Thanks for any feedback on this

[TDK]

Your rising edges look too crisp. Almost like your SDA/SCL pins are in push pull mode rather than open-drain.

Looks like an issue on the host side rather than the device side.

[ArnoutDekimo]

The reason they look "crisp" imo is because I lowered the frequency from the theoretical 1Mhz to 50khz. Slow anything down sufficiently, and it will look like a perfect square, no matter what the pullups/driving. 

[ArnoutDekimo · Accepted solution]

The issue ended up being nothing related to I2C at all, but a delay timer issue in the driver code.

The linux driver I was using lacked the fix from https://github.com/torvalds/linux/commit/ea85bf906466191b58532bb19f4fbb4591f0a77e. Basically it did not wait long enough for the sample to be ready before reading it out.

I got completely sidetracked when looking at the I2C traces, which, still, are very unusual (but can be caused by either the IMX host itself or the device - I did not further investigate).