ASM330LHH reading wrong measurements in X,Y gyroscopes when applying a temperature cycle

[trainty]

I work for a company that has used this IMU for some of the new designs (we have currently assembled and tested +1000 units with ASM330LHH) and we have noticed that some of the units (around 10 %), are presenting a strange behaviour when subjecting them to temperature cycles, the effect has only been noticed in X and Y axes, never in Z. Here is a plot of the behaviour:

 

The x-axis of the graphs represent the incremental samples, and the y-axis in the left-hand side represents the raw decimal number read in the 16-bit registers. The y-axis in the right-hand side is the temperature in ºC.

The unit is completely static in a controlled environment, a temperature chamber. There is evidence that there has not been any physical motion during the peaks, due to the information provided by additional accelerometers in the same PCB. The ASM330LHH accelerometers do not show this behaviour.

As it can be seen, the unit presents wrong measurements at similar temperatures. In all the tests where this has happened, the effect is seen at approximately similar temperature (+-10 deg) in one unit. When changing the unit, this effect can be repeated at other temperature. The effect does not always happen with the same unit, the effect is not perfectly repeateable.

 

Here is the configuration I'm using in terms of registers:

CTRL4_C: 00000110

CTRL9_XL: 11100010

CTRL3_C: 01000100

FIFO_CTRL1: 00001001

FIFO_CTRL2: 00000000

FIFO_CTRL3: 01111001

FIFO_CTRL4: 00000110

CTRL1_XL: 10011110

CTRL2_G:01110100

CTRL10_C: 00000000

CTRL5_C: 01100000

CTRL8_XL: 01100000

CTRL6_C: 00000101

I'm reading the FIFO registers at 500 Hz, making an average of the available samples at the moment of extracting the values from the FIFO, after clasifying them in accelerometer or gyroscope measurements according to the tag. I'm using SPI communication at 8 MHz in SPI mode 3.

 

Please confirm we are using a meaningful register configuration. Is there any way to avoid this behaviour?

[Federica Bossi]

Hi @trainty ,

Have you tested these units soldered on a board?

[trainty]

Yes, we actually de-solder two of them and we soldered them in the STEVAL-MKI193V1 breakout board and the effect was exactly the same.

[Federica Bossi]

Hi @trainty ,

Ok, I think it is something related to the soldering process.

It may be that the soldering is introducing a mechanical stress to the mems that causes this behaviour.
From our test data, we have never seen this type of issue.

[trainty]

Please, could you reply about this?

[CHROF]

Is there an update? I have the same issue

[trainty]

Hi, the ST support told me that they had tested in mass the sensor and they never saw it. They concluded that the problem might be at application level instead of at component level. If you could share some of your results, I'm sure we could share some impressions

[CHROF]

Thanks for coming back on the topic. The issue I get is even more basic. I receive a 6A instead of a 6B as the who_am_i answer. I think I have some kind of bit error.