cancel
Showing results for 
Search instead for 
Did you mean: 

IIS2DH - multiple interrupts

afr_e2
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:

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
View more

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!

7 REPLIES 7
niccolò
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

Niccolò

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
View more

 

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.

iis2dh.png

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

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ò

Hi Niccolò,

I have selected the IIS2DH.

afr_e2_0-1691485964633.png

My Unico-Iinstallation is
GUI-Version: 9.13.0.0
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.

afr_e2_0-1691493390304.png

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?

Andreas

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)

Niccolò

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.

afr_e2_1-1691747665610.png

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

Thanks in advance for your assistance.

Andreas

 

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  =)

Niccolò