cancel
Showing results for 
Search instead for 
Did you mean: 

Interrupt line not being cleared

RDyla
Associate II

I'm using an H3LIS331DL chip, and relying on the set threshold to trigger an interrupt and go read the data.

Everything is working fine, except occasionally it will freeze and stop reading anything. On investigation, I found the interrupt output line was getting stuck in the high state, even after reading the INT1_SRC register. Reading the register again at a MUCH later time (5 seconds, for example) will clear the interrupt and continue operation.

Img1. A normal data sequence. The interrupt triggers. I read all 6 data registers. I set a new threshold (increase by +1 each interrupt). I read the INT1_SRC register, and the interrupt clears.

0690X0000087hW1QAI.png

Img2. Zoom in at the end of a normal sequence. I've added a second read of the INT1_SRC register as an example to show the IA bit is successfully cleared. Read data went from 0x59 (0b01011001) to 0x19 (0b00011001).

0690X0000087hW6QAI.png

Img3. Fault sequence. Again the interrupt is triggered, the data is read, a new threshold is set. But this time, upon reading the INT1_SRC register the interrupt does not clear.

0690X0000087hWBQAY.png

Img4. Zoom in at end of fault sequence. Again, a second INT1_SRC read was added to show the remaining contents. Even after 2 reads of the register, IA remains active and the interrupt is not cleared. Read data remains 0x59 (0b01011001).

0690X0000087hWGQAY.png

It seems that this happens when two sequential data samples are above the threshold. Rather than clearing after the first interrupt, and then giving a rising edge for the second... it just remains high throughout. This means the ISR is not service on the second interrupt and it gets stuck in the high state.

The easiest way for me to repeat the fault is to set the interrupt threshold to <1G. In this state, I would expect it to continuously trigger at the ODR. But instead, it triggers exactly 1 interrupt and latches high every time.

Any suggestions are appreciated.

3 REPLIES 3
RDyla
Associate II

Further info:

If I repeatedly send a read request to the INT1_SRC register until it clears, the interrupt finally clears at almost exactly 10ms later. I'm running at 100Hz ODR, so that's 1 data sample period.

0690X0000087lXwQAI.png

The interrupt stays low for 2 sample periods, then repeats the cycle. In this example I again have the interrupt threshold set to 0 just to force the conditions to occur consistently.

Eleon BORLINI
ST Employee

hi, did you check if the INT1 interrupt is latched or not latched (CTRL_REG3 22h, LIR1 bit)? And how do you manage the interrupt duration value in INT1_DURATION (reg 33h)? Regards

Hi Eleon,

Thanks for the advice.

LIR1 bit is enabled.

I was leaving the INT1_DURATION as the default, 0.

Setting the duration to 1 seems to fix the issue. Interrupts are cleared immediately upon reading the INT1_SRC. The interrupt then stays low for 2 sample periods before triggering again.

So 2 new questions now:

  1. I'm not sure I understand what the INT1_DURATION register does. Can you explain? I do not want to require 2 consecutive samples over the threshold before triggering. I thought leaving the duration at 0 would accomplish this.
  2. Why doesn't the interrupt trigger every time? After clearing the first interrupt, it waits 2 cycles before getting the next interrupt. This means with ODR of 100 Hz I'm getting interrupts at a rate of 33 Hz. (with thresholds set to 0) Note: Running in Data Ready mode instead does run at 100 Hz as expected. Just curious why the interrupts don't do the same.