we are using the self-test on the LSM6DS3USTR and it has started to fail and is shutting down our production. Is there a known problem that would create this situation? If there is no answer, we may need to shut down the self test to resume production.

[DGree.6]

This is quite urgent!

[Eleon BORLINI]

Hi @DGree.6​ ,

let me better understand the issue... the self test started to fail during your production test in a systematic way (on all the parts) or only sometimes?

In the first case, did you try to test an old LSM6DS3USTR which was good to check if it is still good now?

In the second case, can you share the log of your test in more detail (for example, which axis is failing, or is the test output too low or too high)?

-Eleon

[DGree.6]

It is NOT all devices that are failing. Most are still passing. We did have a software change and I am asking that they revert back to be sure that’s not it. (It’s not very likely, but we must do this test!)
We also have one device that was quite a surprise. When heated up so that the IMU temperature is 38°C, it passes. When cooled down to 25°C, it fails. With only a sample of one, this isn’t much of an indicator.
This started around Wednesday afternoon, and since that moment, the failure rate is 18%. And there have been enough older devices tested since then and have passed to convince me this is something new.
The self-test does not provide ANY answer. So your question about too low or too high doesn’t make sense as I have no data for these failures.
Dale

[Eleon BORLINI]

Hi Dale,

>> The self-test does not provide ANY answer. So your question about too low or too high doesn’t make sense as I have no data for these failures.

As defined in the AN4889 application note at p.117, the self test is the calculation at room temperature (about 25°C, so better to run the self-test in this condition) of the logical AND of the following statements, which are composed of numeric values:

|Min(ST_X)| <=|OUTX_ST-OUTX_NOST| <= |Max(ST_X)|
AND
|Min(ST_Y)<=|OUTY_ST-OUTY_NOST| <= |Max(ST_Y)|
AND
|Min(ST_Z)| <=|OUTZ_ST-OUTZ_NOST| <=|MAX(ST_Z)|

Different thing is if your software doesn't output the single values, but only the PASS / FAIL flag...

>>  We did have a software change and I am asking that they revert back to be sure that’s not it. (It’s not very likely, but we must do this test!)

This is a good way to start narrow down the issue. Please be sure your engineers are discarding the initial data as described

May I ask you if you changed the device LOT from last Wednesday afternoon? You can check it reading the marking on the top of the package.

-Eleon

[DGree.6]

Your logic makes a lot of sense where I have data, but again the problem is that for the failures, I have no data. Applying min/max logic to no data is clearly not possible and that’s where we get stuck. We are using similar min/max logic when the data are available.
I do understand the room temperature issue. This was just an experiment on this one device that gave us an answer at the higher temperature, but no data at room temperature.
It is typically the X, Y, Z of the gyro that doesn’t provide self-test data, but it is also possible that it is the X, Y Z of the accelerometer that doesn’t provide self-test data. In a few rare cases, we have neither accelerometer or gyro data.
I’m still trying to find out if there’s something strange that is done in our firmware that can provide no data, but that did not change when this started. The test software did change, but as I said, we’re trying the previous version of software even though we don’t think that has anything to do with the problem.
Thanks for your attention on this problem. Production has shut down and this is extremely urgent.
Dale

[DGree.6]

There's one thing that we found. We are using two different part numbers LSM6DS3TR and LSM6DS3USTR. I remember hearing that we could use only the 2nd. Is there an important difference between these?
Dale

[Eleon BORLINI]

Hi @DGree.6​ ,

sorry to come back to you so late. There should be no substantial differences between the two part numbers, in theory.

When you are saying:

>> we’re trying the previous version of software even though we don’t think that has anything to do with the problem.

Were you able to try the old samples with the new software, and the new samples with the old software?

-Eleon

[DGree.6]

First, Kirby Atwater gave us details of the differences and we all agree that the part number isn’t likely to be a cause of the problem.
Second, we did test a number of devices with the older software and there was no difference. As I said, we did not expect any. There was no attempt to split good from bad devices, but there were a lot.
Third and weirdest is that we have another product with the same IMU chip and the same LPC1768 processor that it talks to via SPI. When we transplant a “failing�? chip into the other product, things work. However, the quality test on this other product is not the self-test, so this isn’t quite a fair comparison. The test for this other product only puts limits around the expected values of [-1g 0g 0g 0dsp 0dps 0dps] based on the device-and-IMU orientation. When we field-tested a few of the product that is failing the self-test, the IMU functioned as expected. It’s only the self-test that’s failing. So in a panic, we are trying to install the other products limits-applied-to-expected-values test. This is NOT easy as there are other constraints in our testing configuration and may take a few days to get data.
The self-tests that are failing are looking like it may trace back to two reels of IMU chips. Our CM is currently examining their records.
Dale

[Eleon BORLINI · Accepted solution]

Thanks you for the update Dale.

I agree with you the two testing procedure are quite different.

Please consider that there is another part number with a similar name, i.e. LSM6DS3TR-C.

If it can be of some utility, I share you the self test procedure (C code) for the LSM6DS3 (same as LSM6DS3USTR) and the LSM6DS3TR-C. You can find them on Github repository.

• lsm6ds3_self_test.c (please note that last fix was performed 12 days ago, on "data ready check in gyroscope self-test section")
• lsm6ds3tr_c_self_test.c

Please let me know if any progress.

-Eleon

[DGree.6]

We think we may have found a solution which is confirmed only by a very small sample. The word that I get is that there is a string of commands sent to the IMU for the self-test. These commands have now been split into two with a 20ms delay and some conditional tests between. ( I will be asking more questions about these changes today.) I’ll let you know what I find with the larger sample when I get the data.
What we found is that this problem started in the middle of a reel of LSM6DS3 parts. We did try two other reels and the problem persisted. I also heard a rumor that something changed in the firmware in the LSM6DS3. Is that true? If so, it links up with the sudden appearance of the problem after we made many tens of thousands of these devices.
Thanks for the test procedure code, but we cannot use it because of memory and other design constraints of this product. However, I have asked that someone familiar with our code looks it over to see if there’s anything else to be learned from it.
Dale