LIS2DW12 latching INT1 pin to GND on board reboot

[bmatesin]

Hi everyone,

been trying to nail the issue down for a while and I hope someone can help

I've got an LIS2DW12 connected using I2C to an STM32L476VGT6, and I'm trying to set it up to detect WAKEUP

events. I've been following ST's official AN5038 to get it in the right mode of operation.

My steps are as follows, in pseudocode:

1. On boot:
   • on CTRL2 set .SOFT_RESET and write (0x40)
   • wait 1 ms
   • on CTRL2 set .BOOT and write (0x80)
   • wait 25 ms
   • read ALL_INT_SRC to clear any hanging interrupts
2. To set up:
   • on CTRL2 set .BDU and .IF_ADD_INC and write (0x0C)
   • on CTRL1 set .ODR to 25 Hz, .MODE to LOW_POWER, .LP_MODE to LP1 and write (0x30)
   • on CTRL3 set .PP_OD to OPEN_DRAIND, .LIR to UNLATCHED, .H_ACTIVE to ACTIVE_LOW and write (0x38)
   • on CTRL6 set .BW_FILT to ODR/2, .FS to 2g, .FDS to HIGH_PASS_PATH and .LOW_NOISE to TRUE and write (0x0C)
   • on CTRL4 set .INT1_WU and write (0x20)
   • on WAKE_UP_DUR set .WAKE_DUR to 2 and .SLEEP_DUR to 2 and write (0x42)
   • on WAKE_UP_THS set .WK_THSx to 3 (90 mg @ 2 g range) and write (0x03)
   • on CTRL7 set INTERRUPTS_ENABLE and write (0x20)
3. On any interrupt:
   • read ALL_INT_SRC to read-and-clear interrupts
   • pass on to logic

On cold boot from the firmware, everything works, the accelerometer picks up the motions, triggers the interrupt handler, which jumps to an interrupt handling routine and passes on the event elsewhere. Tip-top.

On warm boot (NVIC_reset() or a hardware RESET button tied to the STM32), about 50% of the time the INT1 pin has a chance of getting tied down to GND and I've not been able to force it to unlatch. This is a serious problem because the devices aren't meant to be babysitted, and should resolve on its own.

On the system side:

• battery-powered, 3.6 V DC nominal

On the STM32 side:

• it spends most of its time in a low-power state (μA range), but it never fails to acknowledge interrupts
• the pin itself (PE7) is dedicated for the LIS interrupt, has a 1 MΩ pull-up and nothing else
• there are no other interrupt pins (Px7) sharing the interrupt line - though this might be a red herring because the pin is electrically tied down
• any time there's a register write, there's first a register read to preserve register defaults or old configs
• does not change behaviour if I manually set `PE7` to an output pin, flip it around a couple of times and then reconfigure it as an interrupt pin before setting up the LIS2DW12 driver

On the LIS side:

• its power is permanently tied to VDD
• always works fine on cold boot
• sporadically ties INT1 to GND after reboot
  • seems to happen more frequently if it's rebooted as it's sending an interrupt
• does not change behaviour if I set CTRL3.PP_OD to PUSH_PULL
• does not change behaviour depending on the WAKE_UP_DUR or WAKE_UP_THS registers
• does not react to multiple attempts at the boot procedure
• does not react to a full-register dump (just in case any stuck registers expect a read-to-clear interrupts)

What am I missing here?

[Federica Bossi]

Hi @bmatesin ,

Welcome to ST Community!

Can you try to follow our official example on github and let me know if you still have the issue?

Thanks.

[bmatesin · Accepted solution]

Hi @Federica Bossi,

I found the solution a few days ago but only managed to reply to the thread today.

The cause of the problem was in the CTRL7 register.
In cases where resetting the entire board doesn't reset power to the LIS2DW12, the accelerometer registers retain their values. This is expected.
However, resetting the accelerometer using the CTRL2.SOFT_RESET bit (both as explained in AN5038 Ch5.9 and the driver you linked) did not automatically reset the contents of registers even though the delay after the command was extended to 1 ms.

The CTRL7.INTERRUPT_ENABLE bit remained TRUE, and in some cases the accelerometer would be left with a stuck INT1 output pin. The only solution was to force that bit to FALSE on every microcontroller boot. This solved the problem completely.

I'm unsure if this is a known issue that's unreferenced in both the datasheet and the application note.