Skip to main content
Visitor II
May 16, 2025
Question

MEMS elements inside an accelerometer (LIS2DH12) get stuck

  • May 16, 2025
  • 1 reply
  • 468 views

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,

 

    This topic has been closed for replies.

    1 reply

    ST Employee
    May 16, 2025

    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.

     

    CF3nXftwAuthor
    Visitor II
    May 19, 2025

    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