cancel
Showing results for 
Search instead for 
Did you mean: 

MEMS elements inside an accelerometer (LIS2DH12) get stuck

CF3nXftw
Associate II

I have a device which uses an accelerometer (LIS2DH12) to trigger a wake up upon movement. Now I have a few samples on my hand, where this wake-up does not work.

 

The design, configuration, interrupt, etc of the parts work (as validated by other identical builds). The parts in question, I can also bring back to "normal" operation, by turning VDD off and back on. After such a hard reboot, everything works as it should (this further confirms that the parts on hand do not have an electronic/manufacturing defect). Hence, I could in principle schedule a periodic reboot of the accelerometer, but this defeats the idea of a wake-up interrupt. Is the LIS2DH12 supposed to be rebooted on a regular interval?

 

When the parts are in the "stuck" state, I can communicate (read/write from/to the registers) with the accelerometer. All values appear to be coherent (e.g. the WHO_AM_I, and the CTRL registers report back what I write to them). In other words, the electrical interface still works as intended.

 

It looks as if the MEMS element is stuck: no matter the movement, the wake-up threshold is not reported to be exceeded (as mentioned above, I can change the threshold values (e.g. INT1_THS and INT1_DURATION), which are accepted).

 

To my knowledge, the “stuck” parts have not seen any dramatic/special events. On the other hand, as the accelerometer simply reports “no acceleration”, it seems impossible to determine when (and thus under what environmental conditions) the event occurred.

 

Therefore, is “MEMS element stuck” a known failure mechanism and/or did the development team consider it? If so, under what conditions would this occur (e.g. could the max ratings cause such a behavior: a voltage spike on a pin, excessive acceleration, temperature, ESD)?

With such a list, I could then check whether those conditions have possibly been present.

 

Assuming "MEMS element stuck" cannot happen (at least not in a way that would be reversible by turning off VDD and back on): what (intentional) configurations would disable the accelerometer (e.g. setting CTRL_REG1 to 0x00)?

 

Thank you, best regards,

 

2 REPLIES 2
casadeib
ST Employee

Hi @CF3nXftw 

In our experience the LIS2DH12 does not need to be rebooted after a regular time interval and it is not a behavior that we expect on this device.

In order to further investigate and understand which is the cause of such phenomenon, can you please share with us the device configuration, a register dump of the register map, and maybe the value of the output register once the sensor is "stuck"? Also a log file with the accelerometer values would be helpful.

 

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hi @casadeib 

Thank you for your reply. Here the read values from the various registers. Please note that both the "working" and the "stuck" samples all report the same values.

 

NameAddress (hex)Value (hex)
WHO_AM_I0F33
CTRL_REG01E10
TEMP_CFG_REG1F0
CTRL_REG1203F
CTRL_REG221B9
CTRL_REG32260
CTRL_REG42380
CTRL_REG5240
CTRL_REG6250
REFERENCE260
STATUS_REG27FF
FIFO_CTRL_REG2E0 (not using the FIFO)
INT1_CFG302A
INT1_SRC3115
INT1_THS3212
INT1_DURATION3301
CLICK_CFG380
CLICK_SRC390
CLICK_THS3A0
TIME_LIMIT3B0
TIME_LATENCY3C0
TIME_WINDOW3D0
ACT_THS3E0
ACT_DUR3F0

(I'm a bit puzzled about the value of INT1_SRC, but eitherway, we're only interested in the IA bit, which is reported inactive.)

 

For measured values:

NameAddress (hex)Value (hex)
OUT_TEMP_L0C0 (see TEMP_CFG_REG)
OUT_TEMP_H0D0 (same)
OUT_X_L280
OUT_X_H290
OUT_Y_L2A0
OUT_Y_H2B0
OUT_Z_L2C0
OUT_Z_H2DFF

Here, the "working" sample outputs changing values (e.g. OUT_Y_H = 0x01) on movement.

 

Best regards