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]

Thanks for the reply. I'm not sure if that is the case, due to the fact that the effect is not repeateble with the same unit. It sometimes appears at a specific temperature, sometimes at other temperature and sometimes does not appear. If the unit was soldered poorly, the effects would be seen in a deterministic way, and that is not the case.

The units are assembled and soldered on a professional assembly line following IPC A 610 standard qualities that has even assembled space-grade componentes. The processes complies with the specifications outlined in the datasheet of the ASM330LHH. If additional /especial measures should be taken when soldering this component, please point it out.

Could you confirm that the registers configuration is and the reading routine is correct? I was wondering if we could be making a mistake in our software. The first time I saw the effect I suspected from BDU register, due to the fact that if not active, MSB and LSB could be switched. However, my configuration is activating BDU and the effect is still seen.

We have seen this effect in more than 100 ASM330LHH units, which is a relevant number. There should be an application note or at least comment indicating that this effect can happen if nothing can be done in terms of software.

I can send all the information / raw data needed because we really want to find a technical explanation for the problem.

[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.