2017-10-03 04:21 PM
I am using an
https://community.st.com/tags♯/?tags=lsm6ds3
IMU. I intended to use thehttps://community.st.com/tags♯/?tags=sleep%20wakeup
/sleephttps://community.st.com/tags♯/?tags=interrupt%20issue
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.
#sleep-wakeup #lsm6ds3 #interrupt-issue2017-10-06 01:01 AM
Hello Nick,
unfortunately
LIR bit in TAP_CFG (58h) register doesn't have impact on Activity/Inactivity feature. When the Activity/Inactivity status is detected, the interrupt is set high for 1/ODR_XL[s] period then it is automatically deasserted. So you cant make this interrupt latched.
'
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.'
Can you please explain this problem with WAKE_UP_SRC register in more details, it is not very clear to me.I will try to investigate the problem with interrupt during start-up more, but I think you should ignore any interrupt before the sensor if properly configured and you can configure the sensor when the power supply settle.
2017-10-06 07:47 AM
Miroslav,
Thanks for getting back to me.
I am a little confused about the TAP_CFG LIR bit not affecting the wake/sleep interrupt because in AN4650 Section 5.3 (Wake Interrupt) this behavior is specifically mentioned.
Is this an error in the app note or am I misinterpreting what this paragraph means?
In regard to the WAKE_UP_SRC error, my original post had a typo and should read
' ...when I read WAKE_UP_SRC I will get values like 0x10 during a sleep event (expected) and 0x14 during a wake event, but after a while both events read 0x00 but the interrupt is still firing '
Basically I am able to read the WAKE_UP_SRC register and get meaningful values that correspond the physical wake and sleep conditions but after running for a while the interrupt will still fire (I can see the interrupt pin on my oscilloscope and the MCU still captures the interrupt) but the WAKE_UP_SRC register will contain 0x00 no matter which interrupt (wake or sleep) was actually asserted.
2017-10-09 04:07 AM
Hello Nick,
The LSM6DS3 has two features, which I think we are mixing together.
1) Wake-up interrupt described in chapter 5.3 of the application note AN4650. (MD1_CFG = 0x20) This interrupt can be latched.
2) Activity/Inactivity recognition interrupt described in chapter 5.6. (MD1_CFG = 0x80) This feature is also able to generate interrupt when the device goes to sleep mode and wakes up but these interrupts cannot be latched.
So I think you are using the second feature - Activity/Inactivity - and in this case the interrupts cannot be latched.
Maybe you can share you complete configuration so I can check the behavior with the exactly same condition.