Reading from LIS3MDL interrupt fails the second time.

jaredwolff · ‎2021-11-17

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

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

write to 0x1C nak

Any thoughts are greatly appreciated.

Eleon BORLINI · ‎2021-11-23

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

jaredwolff · ‎2021-11-23

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

Eleon BORLINI · ‎2021-11-26

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

jaredwolff · ‎2021-12-16

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>;

Eleon BORLINI · ‎2021-12-20

Thank you for sharing the solution, @jaredwolff !

jaredwolff · ‎2021-12-20

@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:

The 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 · ‎2021-12-20

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.