IIS2DH - multiple interrupts

[afr_e2]

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:

STATUS_REG_AUX: 0x07
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
TEMP_CFG_REG : 0x1F
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
FIFO_CTRL_REG : 0x2E
FIFO_SRC_REG : 0x2F
INT1_CFG : 0x30
INT1_SRC : 0x31
INT1_THS : 0x32
INT1_DURATION : 0x33
INT2_CFG : 0x34
INT2_SRC : 0x35
INT2_THS : 0x36
INT2_DURATION : 0x37
CLICK_CFG : 0x38
CLICK_SRC : 0x39
CLICK_THS : 0x3A
TIME_LIMIT : 0x3B
TIME_LATENCY : 0x3C
TIME_WINDOW : 0x3D
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!

[niccolò]

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

Niccolò

[afr_e2]

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:

 

STATUS_REG_AUX: 0x00
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_CTRL_REG : 0x00
FIFO_SRC_REG : 0x00
INT1_CFG : 0x2A
INT1_SRC : 0x00
INT1_THS : 0x04
INT1_DURATION : 0x00
INT2_CFG : 0x00
INT2_SRC : 0x00
INT2_THS : 0x00
INT2_DURATION : 0x00
CLICK_CFG : 0x00
CLICK_SRC : 0x00
CLICK_THS : 0x00
TIME_LIMIT : 0x00
TIME_LATENCY : 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?

Andreas

[niccolò]

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)

Niccolò