Posted on April 18, 2017 at 07:48I'm using an LIS3DH accelerometer. It is configuring properly and returning valid data when manually read at a fixed interval. Now I'm trying to switch to the use of its XYZDA signal that is emitted on INT1.
I have all other interrupts on INT1 disabled, and I'm enabling XYZDA by setting bit 4 of CTRL_REG3. If I clear the bit, INT1 stays inactive, and if I set the bit, INT1 starts showing activity, so I'm confident I'm setting the bit I think I am {grin}.
A scope shows that INT1 goes active at ODR intervals, as expected. The problem is INT1 resetting to inactive. Section 3.1.2 of the LIS3DH's app note says 'the interrupt is reset when the higher part of the data of all the enabled channels has been read (29h, 2Bh, 2Dh)'. This seems clear enough... read the MSB of all three axes and INT1 should be cleared.
However, what happens instead is that INT1 clears at variable times, often many tens of milliseconds after the last of the six data bytes has been successfully read. Watching it on the scope, the leading edge of INT1 is locked to ODR but its trailing edge starts very long and then shortens over time, until it appears to get down to where it should be (the last byte of data being read).
This last point is confirmed by watching the clock and data lines of the SPI interface... you can see when the last of the six bytes of data are read, and when INT1's pulse width finally shrinks to that point, it appears to 'snap' back to its ultra-long period and start slowly getting shorter again.
I've read everything I can find on this part. There's an odd lack of timing diagrams or other similar electrical specs in the data sheet and app note, so I don't have any concrete references as to what to expect for INT1 timing. But that 3.1.2 reference in the app note seems unambiguous: The XYZDA interrupt should reset when all three MSB's have been read. That's not happening, AND the delay until it DOES reset is extremely variable.
Anyone have any tips on this? I'd appreciate any assistance.
Thanks!
