LIS2DW12 fails to issue fifo interrupt sometimes

WPuch · ‎2019-03-14

I'm setting up LIS2DW12 to 100Hz, low power mode 1, fifo threshold 30 and fifo interrupt on INT2.

When interrupt is received by MCU (STM32L4 here) i readout register 0x2F to know how much samples is to retrieve, then retrieve them all by issuing read from address 0x28, length 6*<sample count> bytes. And i receive interrupt about 3 times per second and it almost works.

To be exact it works for about 30 seconds or so, then LIS2DW12 fails to raise interrupt.

By "pushing it" by manually connecting power supply wire for short time to INT2 line it again works, until some time it again fails.

Where should i seek a source of this problem? I have no idea for now.

Eleon BORLINI · ‎2019-03-14

hi, for my understanding are you in Continuous mode? I assume you configured INT2 pin by writing the INT2_FTH bit to '1' in register CTRL5_INT2_PAD_CTRL (24h). Which is the FIFO threshold flag (FIFO_FTH) when the interrupt INT2 fails?

moreover, are there hw components on INT2 (which is an in/out line, see p.16 of the ds) the electrical track?

just for debug, if INT1 is available in your app, you could try to read INT2 interrupt on it by setting 1 to INT2_ON_INT1 bit in CTRL7 (3Fh).

Regards

WPuch · ‎2019-03-15

On 2019.03.14 17:25, ST Community wrote:
right. i use continous mode. Fmode=0b110 threshold=0x1E (30), but
different threshold doesn't change things.
I set up CTRL4_INT1_PAD_CTRL to 0x06 - both fifo threshold and fifo full
just for sure.
INT2 line is directly connected to STM32L452RE G14 pin, INT1 directly to
G9 pin. CPU is in stop2 mode normally and waken up by exti interrupt.
Tries changing everything to use INT1. Same effect.
When it stall tried "forcing" interrupt by touching this line with Vdd
wire to generate one interrupt manually. It then start again to work
for some 15-60 seconds properly and stops.
Of course i can get rid of this interrupts altogether and use RTC to
wake up CPU every second or half but it isn't i think the clean solution.

WPuch · ‎2019-03-15

this is my procedure that is called after EXTI interrupt is serviced (not directly from interrupt, i made my own simply event driven system):
(no HAL, my own procedures but i think it's clear.
int fifo_samples;
short dane[32*3],*danep;
i2c_start(PODSTAWOWE_I2C);
fifo_samples=I2C_ReadMemory1(PODSTAWOWE_I2C,ACCEL_ADR,0x2F)&0x3F;
print_time();
printf("Accelerometer INT1 - %d samples.\n",fifo_samples);
if(fifo_samples) {
I2C_ReadMemory(PODSTAWOWE_I2C,ACCEL_ADR,0x28,6*fifo_samples,(uchar*)dane);
if(fifo_samples>3) fifo_samples=3;
fifo_samples*=3;
danep=dane;
//display how much samples left is in fifo and first 3 samples
printf("**%02X** ",I2C_ReadMemory1(PODSTAWOWE_I2C,ACCEL_ADR,0x2F)&0x3F);
while(fifo_samples--) printf("%5d ",*(danep++));
print_konsola("\n");
}
i2c_stop(PODSTAWOWE_I2C);
while my initialization procedure is as below:
//check for accelerometer present
if(ACCEL_ID!=I2C_ReadMemory1(PODSTAWOWE_I2C,ACCEL_ADR,0x0F)) {
print_konsola_time("Accelerometer not found.\n");
return;
}
const uchar i2c_setup_1[]={0x50,0x04,0x00,0x06,0x00,0x00};
//first reset then configure registers
if(I2C_WriteMemory1(PODSTAWOWE_I2C,ACCEL_ADR,0x21,0x44)||
    I2C_WriteMemory(PODSTAWOWE_I2C,ACCEL_ADR,0x20,6,i2c_setup_1)||
//rejestr FIFO_CTRL na 0xDE - Fifo continous, threshold 30
    I2C_WriteMemory1(PODSTAWOWE_I2C,ACCEL_ADR,0x2E,0xDE)||
//enable interrupts
    I2C_WriteMemory1(PODSTAWOWE_I2C,ACCEL_ADR,0x3F,0x20)) {
print_konsola_time("Accelerator setup error.\n");
}
the net result is (ignore time data in this):
.
.
.
lots of lines like below
.
[2017.01.01 00:24:08] Accelerometer INT1 - 30 samples.
**03** -976 1376 -16464 -608 1312 -16352 -896 1072 -16720
[2017.01.01 00:24:08] Accelerometer INT1 - 30 samples.
**03** -976 1088 -16528 -656 1552 -15648 -608 1104 -16064
[2017.01.01 00:24:09] Accelerometer INT1 - 30 samples.
**03** -1152 1264 -16384 -480 1248 -16512 -848 1792 -15760
[2017.01.01 00:24:09] Accelerometer INT1 - 30 samples.
**03** -1008 1072 -16528 -576 1616 -16288 -800 1392 -16560
[2017.01.01 00:24:09] Accelerometer INT1 - 30 samples.
**03** -976   800 -16576 -640 1312 -16448 -896 1424 -16896
[2017.01.01 00:24:10] Accelerometer INT1 - 30 samples.
**03** -976 1024 -16144 -896 1552 -16096 -1104 1008 -16368
[2017.01.01 00:24:10] Accelerometer INT1 - 30 samples.
**03** -1040 1040 -16224 -768 1040 -17056 -688   640 -16352
and then stop.
On 2019.03.14 17:25, ST Community wrote:

WPuch · ‎2019-03-15

Thank you for your help. Problem was "solved". Or to be exact i proved it's not accelerometer fault, but EXTI problem on STM32 side.
I used RS232 to USB converter as interrupt generator and found sometimes interrupts are missed.
I will look at it more and possibly write other question but not on accelerometer group.
On 2019.03.14 17:25, ST Community wrote: