LIS2DH12 accelerometer values suddenly close to zero (-4, 0, 4)

veli-matti · ‎2017-11-14

Posted on November 14, 2017 at 21:08

Dear all

We are using LIS2DH12 accelerometer in our product. We are juat about to launch the production and sales when we faces a weird problem.

Suddenly the accelerometer starts reporting values like 0, 4 and -4, instead of normal values somewhere around 1000 and 0 when not moving the device.

In error situation the values don't change even when rotating or shaking the device.

Register writes and reads are successful and WHO_AM_I (0x0f) register value matches to 0x33 so there's no address conflict.

I tried to fix the problem by resetting the registers to initial values. This didn't fix the problem. Also I tried to assert the BOOT bit of CTRL_REG5, which didn't help either. (I'm not quite sure what that is supposed to do)

Powering down the accelerometer is the only thing that helps. Too bad we don't have that possibility in our device. Removing the battery is the only possibility, which can be done only with opening the device using screwdriver.

The error is quite rare and we don't know the root cause.

Could anyone help? This is getting quite urgent.

My init sequence is:

// Try the BOOT bit with no help.

Write LIS2DH_CTRL_REG5, _CTRL_REG5_BOOT

delay 5 ms to wait the boot to complete.

//Restore default values:

Write LIS2DH_CTRL_REG0, 0x10

Write LIS2DH_TEMP_CFG_REG, 0x00

Write LIS2DH_CTRL_REG1, 0x07

Write LIS2DH_CTRL_REG2, 0x00

Write LIS2DH_CTRL_REG3, 0x00

Write LIS2DH_CTRL_REG4, 0x00

Write LIS2DH_CTRL_REG5, 0x00

Write LIS2DH_CTRL_REG6, 0x00

Write LIS2DH_REFERENCE, 0x00

Write LIS2DH_FIFO_CTRL_REG, 0x00

Write LIS2DH_INT1_CFG, 0x00

Write LIS2DH_INT1_THS, 0x00

Write LIS2DH_INT1_DURATION, 0x00

Write LIS2DH_INT2_CFG, 0x00

Write LIS2DH_INT2_THS, 0x00

Write LIS2DH_INT2_DURATION, 0x00

Write LIS2DH_CLICK_CFG, 0x00

Write LIS2DH_CLICK_THS, 0x00

Write LIS2DH_TIME_LIMIT, 0x00

Write LIS2DH_TIME_LATENCY, 0x00

Write LIS2DH_TIME_WINDOW, 0x00

Write LIS2DH_Act_THS, 0x00

Write LIS2DH_Act_DUR, 0x00

//Set 100Hz normal mode

Write 0x20, 0x57

Write 0x23, 0x80

//Enable FIFO (Streaming)

Write LIS2DH_CTRL_REG5, _CTRL_REG5_FIFO_EN

Write LIS2DH_FIFO_CTRL_REG, 0x80

//Init Interrupts:

Write LIS2DH_CTRL_REG3, _CTRL_REG3_I1_CLICK | _CTRL_REG3_I1_AOI1

Write LIS2DH_CTRL_REG6, _CTRL_REG6_H_LACTIVE

Write LIS2DH_INT1_CFG, _INT1_CFG_AOI | _INT1_CFG_XHIE_XUPE | _INT1_CFG_YHIE_YUPE | _INT1_CFG_ZHIE_ZUPE

Write LIS2DH_INT1_THS, 1

Write LIS2DH_INT1_DURATION, 1

Write LIS2DH_CLICK_CFG, _CLICK_CFG_ZS | _CLICK_CFG_YS | _CLICK_CFG_XS

Write LIS2DH_CLICK_SRC, _CLICK_SRC_SClick

Write LIS2DH_CLICK_THS, 3

In the following there is a sample of erroneous FIFO stream.

<xyz: 4,-4,0>

<xyz: 4,0,4>

<xyz: 0,0,0>

<xyz: 0,4,4>

<xyz: 0,0,0>

<xyz: 0,4,4>

<xyz: 4,0,0>

Reading values directly from out registers starting from 0x28 return similar values (-4, 0, 4, sometimes 😎

#lis2dh12

Miroslav BATEK · ‎2017-11-15

Posted on November 15, 2017 at 15:37

Is the sensor connected to microcontroller by I2C or SPI bus?

If the SPI is used, is any other device connected on the same bus?

veli-matti · ‎2017-11-15

Posted on November 15, 2017 at 15:45

Sensor is connected over I2C. There is a LED driver also on that bus. There's no data traffic to the LED driver after the device init procedure.

Miroslav BATEK · ‎2017-11-15

Posted on November 15, 2017 at 16:09

It will be tough to debug this issue remotely.

What is the average run time after which the sensor start send weird data?

Is is case of one sensor or do you have more prototypes with the same behavior?

Are you checking the FIFO_SRC_REG register to get correct number of sample in FIFO?

Here is a few ideas which you can check:

- Do you have enough blocking capacity close to the sensor? Some short supply voltage drop can influence the sensor.

- Can you check the I2C signals with a scope? Some peak or disturbances could cause writing to some internal register and cause malfunction.

- You can decrease the speed of I2C pins on your microcontroller.

- You can also try to decrease the I2C speed.

- I would be good to check your sensor configuration and reading procedure, but it seems it will ok if the sensor is working for some time.

veli-matti · ‎2017-11-15

Posted on November 15, 2017 at 16:32

What is the average run time after which the sensor start send weird data?

Is is case of one sensor or do you have more prototypes with the same behavior?

We have been testing the devices quite a lot. We have seen this issue only twice on two different devices. A set of ten devices have been running for days and weeks just fine

Are you checking the FIFO_SRC_REG register to get correct number of sample in FIFO?

Yes.

- Do you have enough blocking capacity close to the sensor? Some short supply voltage drop can influence the sensor.

- Can you check the I2C signals with a scope? Some peak or disturbances could cause writing to some internal register and cause malfunction.

- You can decrease the speed of I2C pins on your microcontroller.

- You can also try to decrease the I2C speed.

- I would be good to check your sensor configuration and reading procedure, but it seems it will ok if the sensor is working for some time.

The I2C signal seems to be nice and no glitches are visible. Although we have not been watching the lines when the error happens. In general the I2C communication works OK, even in the error case. The I2C is operated at 100kHz.

The Voltage drop could be possible, as we have a battery operated device. Is there any way to recover other than hard POR. There's no possibility to do soft POR in this device?

Is it possible to read and store the status of some internal/undocumented registers and try to recover them, if the error occurs?

Do you think the SOFT_RESET in LIS2HH12 would fix this kind of error case? LIS2HH12 is pin compatible with LIS2DH12 and it has option to do soft reset (CTRL5:SOFT_RESET: Soft reset, it acts as POR when 1, then goes to 0)

Miroslav BATEK · ‎2017-11-16

Posted on November 16, 2017 at 14:19

I don't think using LIS2HH12 will help, the soft reset (LIS2HH12) and boot (LIS2DH12) do more or less the same.

It is not possible to recover values of the internal registers.

The only solution I see it to avoid voltage drop under 1.7V.

veli-matti · ‎2017-11-16

Posted on November 16, 2017 at 16:17

Thanks Miroslav for your answer. I'll inspect the voltage lines whether or not there are glitches, especially in case of low battery or high load. We do have 220nF capacitor in the power line next to the regulator another 0.1uF capacitor right next to accelerometer.

Related to boot and soft reset registers. Could you elaborate the difference a bit?

LIS2HH12 seems to have both available.

Miroslav BATEK · ‎2017-11-17

Posted on November 17, 2017 at 15:12

I'm afraid that one 100nF capacitor is not enough. The 100nF + 10uF blocking capacitors are recommended in the datasheet.

Even if you don't have dedicated place on your prototype, I would try to stack some capacitor with value several uF on top of the 100nF capacitor close to the sensor and check if the problem remains.

I asked the sensor specialists what is the difference between BOOT and SOFT_RESET in LIS2HH12, I will let you know.

veli-matti · ‎2017-11-19

175926CGIL2

veli-matti · ‎2017-11-24

Posted on November 24, 2017 at 10:23

We found a way to do a power down cycle to reboot the whole board using charger IC and do SW recovery without having major impact on the device operation.

We didn't find the root cause of the failure, since this is so rare. Based on our measurements there are no voltage drops even close to 1.7V.