cancel
Showing results for 
Search instead for 
Did you mean: 

LIS2DW12 fails to issue fifo interrupt sometimes

WPuch
Associate II

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.

4 REPLIES 4
Eleon BORLINI
ST Employee

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

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