cancel
Showing results for 
Search instead for 
Did you mean: 

Reading from LIS3MDL interrupt fails the second time.

jaredwolff
Associate II

Hey All,

I'm trying to read from an LIS3MDL after a threshold interrupt. While I configure everything ok and receive interrupts the chip only responds to the first event. All subsequent events fail. Here's the setup:

write to 0x1C ack data: 0x0F 

read to 0x1C ack data: 0x3D

write to 0x1C ack data: 0x20 0x80 0x00 0x00 0x00 0x40 

write to 0x1C ack data: 0x22 

read to 0x1C ack data: 0x00

write to 0x1C ack data: 0x22 0x02 

write to 0x1C ack data: 0x20 0x98 

write to 0x1C ack data: 0x22 0x00 

write to 0x1C ack data: 0x22 

read to 0x1C ack data: 0x00

write to 0x1C ack data: 0x22 0x02 

write to 0x1C ack data: 0x32 0x30 0x75 

write to 0x1C ack data: 0x22 0x00 

write to 0x1C ack data: 0x30 0xED 

(Side note, I was putting the device to idle before configuring interrupt, etc b/c I didn't know what was causing this lock up)

Then here's the read:

write to 0x1C ack data: 0x27 

read to 0x1C ack data: 0xFF

write to 0x1C ack data: 0xA8 

read to 0x1C ack data: 0xE8 0x6F 0x57 0xD8 0xD8 0x7F 0xE8 0x6F

0693W00000GXyjGQAT.png 

If another interrupt happens after that, the device doesn't respond: (nothing happens in between)

write to 0x1C nak

 0693W00000GXyjLQAT.png 

Any thoughts are greatly appreciated.

7 REPLIES 7
Eleon BORLINI
ST Employee

Hi @jaredwolff​ ,

from the first picture it looks that the INT is latched. Did you configured it by purpose?

Note, from the datasheet p.29, that if you want to clear it you have to:

Once latched, the INT pin remains in the same state until INT_SRC (31h) is read.

So, in order to clear a latched interrupt you have to read the reg 31h after the interrupt has been raised.

-Eleon

Hi @Eleon BORLINI​ 

Thanks for the reply!

I don't believe it's latched. I can put a magnet in place and it will drive the INT pin and then release when it's removed. (The red trace above in each of the captures is the INT pin) The only thing I did, I believe, is change the polarity of the INT pin. (Active high)

If you have any other thoughts, please let me know. Thanks again.

Jared

Hi Jared @jaredwolff​ ,

I'm wondering if the magnetic field you might not exceed the Maximum exposed field of 1000 gauss, defined in the datasheet, p.12.

Which magnetic field strength are you using in your application?

If it is exceeding the absolute maximum ratings, probably the LIS3MDL is somehow resetting and it is working no more after the first interrupt.

-Eleon

Turns out it was related to how I was retrieving data from the device. The burst reads were not reading properly. This is due to how the driver for my uC is written in Zephyr.

It required this to be added to my I2C device in my Zephyr board overlay.

zephyr,concat-buf-size = <256>;

Thank you for sharing the solution, @jaredwolff​ !

jaredwolff
Associate II

@Eleon BORLINI​ 

I spoke too soon. I'm still seeing this behavior. It appears to be intermittent and very frustrating, to say the least, to debug!

I'm wondering if the magnetic field you might not exceed the Maximum exposed field of 1000 gauss, defined in the datasheet, p.12.

I'm currently using a very small magnet for testing. Not sure what the gauss generated by it but I'm assuming it's fairly small?

When it does work here are some values produced:

[00:07:33.956,542] <inf> app_sensor: Values X: 2.449283 Y: 0.208564 Z: 4.772288
[00:07:50.584,472] <inf> app_sensor: Values X: 4.766150 Y: -3.4823 Z: 4.260011
[00:07:51.922,485] <inf> app_sensor: Values X: 1.639432 Y: -3.410698 Z: 4.468722

When it doesn't work, I get a successful interrupt on the INT pin but it doesn't respond (no ACK) over I2C.

For example, here are three events one right after each other. I'm able to read the first time, NACKs the second and then continues to work on the third:

0693W00000HpJucQAF.png 

0693W00000HpJuhQAF.png 

0693W00000HpJumQAF.pngThe red trace is the interrupt signal. White is CLK. Orange is SDA.

Which magnetic field strength are you using in your application?

Our default here is ±4.

jaredwolff
Associate II

In some cases, if I reset my main uC, I'm unable to communicate or even get a register address. It's as if the SA0 pin is floating but it's pulled to ground. So maybe it's a bad ground return path. I'm playing with pulling the pin directly to ground. Stay tuned.