cancel
Showing results for 
Search instead for 
Did you mean: 

ISM330DHCX I2C issue

ArnoutDekimo
Associate III

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:

ArnoutDekimo_0-1721829511164.png

Zoomed in point 1:

ArnoutDekimo_2-1721829799447.png

ArnoutDekimo_3-1721829824422.png

 

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

ArnoutDekimo_5-1721834361984.png

ArnoutDekimo_6-1721834369931.png

 

 

 

Zoomed in point 2:

ArnoutDekimo_4-1721829878049.png

Reproduction of point 2:

ArnoutDekimo_7-1721834762641.png

 

 

 

 

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:

ArnoutDekimo_8-1721835956626.pngArnoutDekimo_9-1721835969872.pngArnoutDekimo_10-1721835981383.pngArnoutDekimo_11-1721835991829.png

 

Scenario 2:

ArnoutDekimo_12-1721836008839.png

 

 

 

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

 

Thanks for any feedback on this

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
ArnoutDekimo
Associate III

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).

 

View solution in original post

3 REPLIES 3
TDK
Guru

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.

If you feel a post has answered your question, please click "Accept as Solution".

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
Associate III

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).