Showing results for 
Search instead for 
Did you mean: 

IIS2DH - multiple interrupts

Associate II

I've changed from LIS2DH to IIS2DH, without changing the drivers sources. According to the datasheet, there should be no problem doing this.

In the application the accelerator is used to detect each motion of the device. If the device keeps un-motioned, it will channge an internal state into deepsleep. Once motioned again, the device will be waked up. When woken up, some other actions will be done.

Now I have the problem, that the IIS2DH sets multiple interrupts on INT1. Reading the INT1_SRC register multiple times don't effect, that the IA bit is cleared (as described in the datasheet).

My configuration:

OUT_ADC1_L    : 0x08
OUT_ADC1_H    : 0x09
OUT_ADC2_L    : 0x0A
OUT_ADC2_H    : 0x0B
OUT_ADC3_L    : 0x0C
OUT_ADC3_H    : 0x0D
WHO_AM_I      : 0x0F
CTRL_REG0     : 0x1E
CTRL_REG1     : 0x20
CTRL_REG2     : 0x21
CTRL_REG3     : 0x22
CTRL_REG4     : 0x23
CTRL_REG5     : 0x24
CTRL_REG6     : 0x25
REFERENCE     : 0x26
STATUS_REG    : 0x27
OUT_X_L       : 0x28
OUT_X_H       : 0x29
OUT_Y_L       : 0x2A
OUT_Y_H       : 0x2B
OUT_Z_L       : 0x2C
OUT_Z_H       : 0x2D
INT1_CFG      : 0x30
INT1_SRC      : 0x31
INT1_THS      : 0x32
INT2_CFG      : 0x34
INT2_SRC      : 0x35
INT2_THS      : 0x36
CLICK_CFG     : 0x38
CLICK_SRC     : 0x39
CLICK_THS     : 0x3A
TIME_LIMIT    : 0x3B
ACT_THS       : 0x3E
ACT_DUR       : 0x3F

Sometimes just one interrupt accurs, but often there are upto 6 interrupts caused by a single event. The Interrupts come up cyclic every 3 seconds.

Is there a known issue? If so: Is there a known workarround?

Thanks for helping!

ST Employee

Hi @afr_e2 ,

the fact that different interrupts are triggered depends probably on the fact that you configured them with register INT1_CFG (30h), right? you can change interrupt generation from that register, if you only want one direction of motion detected =)

also, try to set LIR_INT1 bit in reg CTRL_REG5 (24h) to be sure that you have to read the INT1_SRC register to restart the interrupt generation

If this answers your question, please, mark this as "best answer", by clicking on the "accept as solution" to help the other users of the community


Hi Niccolò,

thank you for answering my question. Please excuse me for giving the addresses instead of the configuration. So here is the current configuration:


OUT_ADC1_L    : 0x00
OUT_ADC1_H    : 0x00
OUT_ADC2_L    : 0x00
OUT_ADC2_H    : 0x00
OUT_ADC3_L    : 0x00
OUT_ADC3_H    : 0x00
WHO_AM_I      : 0x00
CTRL_REG0     : 0x10
TEMP_CFG_REG  : 0x00
CTRL_REG1     : 0x1F
CTRL_REG2     : 0x09
CTRL_REG3     : 0x40
CTRL_REG4     : 0x00
CTRL_REG5     : 0x08
CTRL_REG6     : 0x00
REFERENCE     : 0x00
STATUS_REG    : 0x00
OUT_X_L       : 0x00
OUT_X_H       : 0x00
OUT_Y_L       : 0x00
OUT_Y_H       : 0x00
OUT_Z_L       : 0x00
OUT_Z_H       : 0x00
FIFO_SRC_REG  : 0x00
INT1_CFG      : 0x2A
INT1_SRC      : 0x00
INT1_THS      : 0x04
INT2_CFG      : 0x00
INT2_SRC      : 0x00
INT2_THS      : 0x00
CLICK_CFG     : 0x00
CLICK_SRC     : 0x00
CLICK_THS     : 0x00
TIME_LIMIT    : 0x00
TIME_WINDOW   : 0x00
ACT_THS       : 0x00
ACT_DUR       : 0x00


In the INT1_CFG register I have activated the "High" direction in "OR Combination" for all three axes. I also set the LIR_INT1 bit in CTRL_REG5. My expectation is that a movement will trigger an interrupt, which I can reset by reading the INT1_SRC register.


Reading at this address clears the INT1_SRC (31h) IA bit (and the interrupt signal on the INT1 pin) and allows the refresh of data in the INT1_SRC (31h) register if the latched option was chosen.


However, I notice that the IA bit remains set even if I read the INT_SRC register multiple times in a loop. So the chip seems to behave differently than described in the data sheet.

Incidentally, I can also reproduce this behavior with the STEVAL-MKI109V3 and STEVAL-MKI168V1.


After the first interrupt i read the register INT1_SRC, so the INT1 line went low, but rises again. Is there an explanation/solution for this?


Hi Andreas @afr_e2 ,

may I ask you which sensor did you select in Unico?

also, maybe the drivers change are required, even if the datasheets are pretty similar (sometimes between the Industrial and consumer version of the sensors, there are specific functions that change)


Hi Niccolò,

I have selected the IIS2DH.


My Unico-Iinstallation is
Firmware-Version: V3.6.26
Demonstration kit selected: STEVAL-MKI168V1 (IIS2DH)
Board: ProfiMEMSTool

As far as I understay the Datasheet, in this case there should be no difference to the LIS2DH. I just tested it with an LIS2DH device and have seen the same issue. So obviously we've always had the problem, it just hasn't been identified yet. :see_no_evil_monkey:

The Interrupt view from unico software shows, that the acceleration values are smoothed. If a movement is detected, the acceleration values rise sharply and then fall in an e - function. As long as this value is above the threshold, interrupts are triggered.


If the REFERENCE register is read out, the mean value is apparently reset. In addition, reading and resetting the INT1_SRC seems to be related to the sampling rate (ODR config). This would also explain why the register can be read multiple times without the line being reset.

Are these observations correct?


Hi Andreas @afr_e2 ,

thanks for sharing the Unico configuration, I asked for support on that side.

regarding your observation, I don't really get what you are saying =\
the REFERENCE reg is for resetting HP filter normal mode, so it is normal that it has some effect on data.
reading the registers is not linked to the ODR, so I don't really understand your concern

back to the actual issue, can you try to change the DURATION register (33h)?
if you try to have a longer duration (depending on what you need, you could fix the issue)


Hi Niccolò,

thanks for your response. When reading the INT1_SRC register, the IA bit still keeps set and the INT1-Line also keeps high. After a short delay, the INT1-Line will go low. I assume, that the delay depends on the settings in the ODR. Is that correct?

I tried out to play with the INT1_DURATION. What I have seen is a delay between the movement and the INT1-Line, when increasing the DURATION. But this doesn't fix the issue.


If reading the REFERENCE resets the filter, this would be a possible way to handle with that phenomen.

Thanks in advance for your assistance.



Hi Andreas @afr_e2 ,

did you try to disable the High Pass filter?
if you look at the data, it is normal that the interrupt returns high (if the interrupt is the light blue line, and if the threshold is low enough) because the data is high enough to trigger the interrupt ( can't be sure without the scale, but it seems that way)

Let me know if this solves the issue  =)