AnsweredAssumed Answered

LSM6DS3 Wake/Sleep Interrupt Fails to Latch

Question asked by Nick Trevethan on Oct 4, 2017
Latest reply on Oct 9, 2017 by Miroslav B

I am using an lsm6ds3 IMU. I intended to use the sleep wakeup/sleep interrupt to drive the MCU into the corresponding state. I believe I have the interrupt configured properly (active high, out on INT1) as I can see it (both the wake and sleep conditions) on an oscilloscope and the MCU receives and processes the interrupt as expected. My issue is with how the latching behavior of the interrupts. I want the interrupt to be asserted until I read the WAKE_UP_SRC  (0x1B) register. I thought all I needed to do was write 0x01 to the TAP_CFG (0x58) register. Unfortunately this doesn't seem to have any effect - the interrupts continue to automatically de-assert themselves no matter what value is in TAP_CFG. I read the value of the register after writing 0x01 to it and the returned value was 0x01.

 

I also tried writing 0x80 just to see if I need to flip the bit order that I was sending to no affect (I wasn't really expecting it to - I can read and configure all the XL and GYR registers just fine). I am wondering if this issue may have something to do with the order of setting the Accelerometer and Gyroscope ODR and filtering settings and the latch bit (do I need to set one before the others or can I do this dynamically?

 

I have also noticed the interrupt is asserted during the power up stage of the system - the interrupt voltage matches the exponential ramp up to 3.3v until about 2.7 volts where the interrupt line immediately falls to 0. I haven't looked too seriously into this issue yet, I think it might be my MCU turning the pulldown resistor on when the interrupt falls but I have no idea why the interrupt pin rises so high/matches the system power up curve during power up (perhaps my power ramp up takes too long?). 

 

On a semi-related note, when I read WAKE_UP_SRC I will get values like 0x10 during a sleep event (expected) and 0x14 during a sleep event, but after a while both events read 0x00 but the interrupt is still firing. I am guessing this is related to not being in-sync with the de-assert time on the IMU which should be fixed by getting the latching behaviour to work properly. 

Outcomes