LSM6DS3: DRDY stops driving INT1

[IDEngineer]

Sorry for all the postings, but we're under a deadline and really struggling with the reliability of the LSM6DS3.

Here's another of the strange things we're seeing on the LSM6DS3: It just stops driving DRDY on INT1. Since our present design relies on INT1 to signal that a new set of XYZ data is ready, when this happens we stop obtaining new acceleration data.

I've confirmed that when this happens the LSM6DS3 is still able to communicate via SPI. In fact, I'm even able to read back all of the configuration registers and confirm that they have the proper values - the values that got the LSM6DS3 running properly in the first place! So it appears that the LSM6DS3 still has the proper register values, but it just stops asserting INT1.

Here are the contents of the registers we confirm (we first write those that are not read-only):

INT1_CTRL/0x0D = 0x01 (B0 set causes DRDY to drive INT1)

INT2_CTRL/0x0E = 0x00 (not using INT2)

WHO_AM_I/0x0F = 0x69

CTRL1_XL/0x10 = 0x80 (1.66KHz high performance,

CTRL2_G/0x11 = 0x00 (gyro powered down for now)

CTRL3_C/0x12 = 0x44 (block data update, INT active high, push-pull, auto-inc, little endian)

CTRL4_C/0x13 = 0x0C (disable data during mode changes, SPI only)

CTRL5_C/0x14 = 0x00 (no rounding, no self tests)

CTRL6_C/0x15 = 0x00 (gyro disabled)

CTRL7_G/0x16 = 0x00 (gyro disabled)

CTRL8_XL/0x17 = 0x00 (defaults for acc filters)

CTRL9_XL/0x18 = 0x38 (enable all three acc axes)

...and we are, indeed, able to read these values back even after the LSM6DS3 has stopped asserting DRDY/INT1. With all three accelerometer axes enabled, an ODR of 1.66KHz, and the accelerometer DRDY enabled on INT1, we should be seeing INT1 asserted every 600uS. And we do - for a while. Then it just stops, even though all of the above register settings are still there (in fact, I typed the above values from a fresh read of them while the LSM6DS3 is failing to assert INT1).

What are we missing here? What would cause the LSM6DS3 to properly assert INT1 for a while, then just stop?

[IDEngineer]

More: I have confirmed that a power cycle to the LSM6DS3 corrects the problem and allows INT1 to be asserted again.

Even more interesting: I have confirmed that leaving power applied to the LSM6DS3, and invoking its SW_RESET function by setting B0 of CTRL3_C/0x12, also corrects the problem.

This suggests to me that the LSM6DS3 is getting into some sort of lockup mode internally. Its config registers say one thing, but it behaves in another. Rewriting the config registers does NOT correct it. But a power cycle, or a SW_RESET, does correct it.

Hopefully this additional data will help with the diagnosis. Obviously we'd like to proactively PREVENT this problem from happening by doing some extra step(s) in configuration, rather than reacting to it in real time.

Thanks!

[IDEngineer]

Even more: It appears there is a bug in the LSM6DS3 that changes its ODR from our setting of 1666Hz (600uS) to some other value. We've seen 416Hz (2400uS) and 12.5Hz (80mS) so far. Again, the registers still contain the proper values (we read them back via SPI to confirm) yet the device's behavior just changes with no warning.

This seems to occur after the device has been free-running for an hour or two. Once we have the LSM6DS3 configured, we simply let INT1 trigger an SPI read of the accelerometer data registers. That's it. We don't write to the LSM6DS3 again. It just sits there generating INT1's at its ODR rate and in response we read six registers. Yet for some reason it's switching to other ODR's - or as noted above, sometimes it just stops asserting INT1 at all.

So far we know:

* Resetting the MCU connected to the LSM6DS3 does NOT fix the LSM6DS3's bug (this causes the MCU to reconfigure the LSM6DS3 from scratch by rewriting its config registers, but since we already confirmed they still contain the correct settings, rewriting them doesn't seem to matter)

* Cycling power to the LSM6DS3 DOES fix its bug

...and we have another test in process to see if, once the LSM6DS3 bug occurs, we can fix it by forcing a SW_RESET instead of a power cycle.

Since the LSM6DS3 registers still contain their proper values, and rewriting those proper values doesn't fix the bug, we suspect this is a hardware/firmware bug INSIDE the LSM6DS3. That would be consistent with it not correcting when the same values are rewritten, but correcting when the power is cycled. It will be very interesting to see if a SW_RESET fixes it.

Obviously we're not happy with the idea that we may have to detect this problem in real time, then constantly fix it on the fly by resetting the LSM6DS3 all the time. Hopefully someone else has seen this behavior and knows of a fix. We'd be thrilled to learn that we have missed something in configuration, etc.

Waiting to hear from someone... thanks!

[IDEngineer]

Update: We ran an overnight test to see if the LSM6DS3 would fail again. Sure enough, overnight it changed its own ODR to a brand new value: 50mS (20Hz), which isn't even a published rate in the spec sheet!

We completely reset everything to start a fresh test (DUT completely powered down, etc.) and we're now waiting for the ODR to change itself again so we can perform some more detailed analysis on the LSM6DS3 once it's failed again.

[IDEngineer]

OK, we've got hard-core data on this LSM6DS3 bug now.

It only took ~40 minutes from a cold, power-off startup for the LSM6DS3 to switch itself from our configured ODR of 1666Hz to (this time) 12.5Hz. We then performed the following tests:

* Confirmed that the LSM6DS3 was still emitting XYZ acceleration data (just at the wrong ODR)

* Confirmed that the LSM6DS3 configuration registers still contained the proper values. The LSM6DS3 was still configured for 1666Hz (600us) but was actually running at 12.5Hz (80mS).

* Rewrote the configuration registers, even though they still had the proper values in them, on the theory that rewriting them might force the LSM6DS3 to reconfigure itself using those values. Rewriting - and reconfirming the write again! - had no effect.

* Finally, forced a SW_RESET... and that fixed the problem, the LSM6DS3 went back to the proper ODR of 1666Hz again.

We've done it many times now, but this test was specifically set up to confirm that 1) the LSM6DS3 is switching ODR's on its own, 2) it does that even though its config registers still contain 1666Hz, and 3) rewriting those proper values back into the config registers doesn't correct the wrong ODR.

So far, the only thing that corrects the bug is a SW_RESET or a power cycle - which means it's an internal error in the LSM6DS3. It's really lucky that the SPI interface is still working and that CTRL3_C is still recognized or there would be no way to recover from this bug without a power cycle.

I'm really hoping someone at ST is paying attention to this thread and will reach out with suggestions. When you send a request for technical support they redirect you to these forums, so here we are... waiting.

[IDEngineer]

More data....

We realized that the bug in the LSM6DS3 seems to only switch its ODR to a lower rate. We've never seen it spontaneously switch to a higher ODR.

To test this, we intentionally changed the ODR to 12.5Hz, the LSD6DS3's slowest rate. All other configuration parameters were unchanged. Then we allowed the unit to run for 36+ hours. If the LSM6DS3 were going to change its ODR, it would have to change it to a higher rate.

Result: NO ODR CHANGE. The scope shows the INT1 properly going active high every ~77mS.

This suggests that the bug in the LDM6DS3 only occurs when the device is configured for high(er) ODR's. Keep in mind that, as noted earlier in this thread, when the LSM6DS3 bug switches its ODR to a lower rate, that lower rate is not consistent... 12.5Hz is common, but we've also seen its 416Hz and 52Hz rates. So the bug seems consistent that it switches to a lower rate, but inconsistent in the specific lower rate that results.

The proof that this is indeed a bug in the LSM6DS3 comes from the fact that when these ODR changes occur, its config registers still contain the settings for the earlier, higher ODR. If you freshly read the chip's config registers via SPI you get YOUR ORIGINAL VALUES, but the chip is now running at a different lower ODR that disagrees with the values you just pulled out of its config registers. Furthermore, freshly rewriting your original values does not snap the chip back into proper operation... only a SW_RESET or power cycle fixes it.

Hopefully all of this data helps someone at ST figure a workaround to correct this LSM6DS3 bug, and post it here in this thread so it is available for everyone to use.

[IDEngineer]

Latest tests ran the LSM6DS3 at 208Hz ODR. We let it run overnight, and this morning the LSM6DS3 was completely locked up. Not even a SW_RESET could fix it. MISO data line never moved off of 0V regardless of what read address was clocked in. Finally, we cycled power to the chip and it started working again.

It's beginning to look like the LSM6DS3 is only reliable at its lowest, 12.5Hz ODR setting. Everything else we've tried ends up dying in some way after a while. This latest failure is especially troubling because it could not be recovered by any sort of firmware action - only a power cycle worked.

Still waiting for any sort of response from ST....

[IDEngineer]

After two more days of testing, we might have an answer.

The bug appears to be related to LPF2, the digital filter block after the A/D. If you look at Figure 5, page 32 of the LSM6DS3's spec sheet, the "Digital LP Filter" and the "Composite Filter" are configurable filters that post-process the output of the A/D converter. Extensive testing suggests that if those digital filters are completely disabled, the LSM6DS3 becomes reliable. But enabling those filters - with any of a variety of configuration options - risks the LSM6DS3 silently switching its ODR (best case) or simply locking up (worst case).

We have multiple LSM6DS3's running on multiple prototype PCB's here and the results are consistent. Given a certain ODR/etc., the LSM6DS3 will continue running properly if the entire digital filter chain is disabled. But if you change nothing else except enable the digital filter, the LSM6DS3 will fail in some way in anywhere from 30 minutes to 24 hours. The time-to-failure is not consistent, and neither are the resulting error modes. In many cases the LSM6DS3's SPI interface remains functional and you can issue a SW_RESET to regain control of the device. But we have seen several failures where the LSM6DS3 becomes completely unresponsive even to its SPI interface and the only way to recover it is to cycle its power.

We have confirmed this behavior with ODR's from 26Hz to 1666Hz. Sometimes the LSM6DS3 failure is to switch to a lower ODR without showing this new ODR in its configuration registers (as noted earlier in this thread). Other times it just "locks up" and SPI becomes unresponsive.

We initially presumed that the digital filter chain in the device was implemented in hardware, and you send configuration parameters via SPI to internal registers that control the filter configuration. However, we now suspect that the digital filter chain is implemented in firmware. This would explain why, sometimes, the bug in the digital filter chain can also take out the SPI interface. If they were implemented separately it should always be possible to command a SW_RESET and regain control.

There is another digital filter, LPF1, whose corner frequency is controlled exclusively by the ODR and it doesn't appear to be possible to disable it. Perhaps the workload represented by this first digital filter doesn't overwhelm the CPU/firmware on the LSM6DS3, but turning on LPF2 is just too much extra and it triggers some edge case that eventually causes the firmware to fail.

Our recommendation is to fully disable the filtering on the LSM6DS3 to the extent possible. After 48 hours of testing on multiple devices across multiple boards, this appears to yield reliable operation. We have implemented our own digital filters in our own code to process the output of the LSM6DS3 and that approach is working fine.

[Eleon BORLINI]

HI IDEengineer, thank you for your effort and the related detailed description of the activity. Sorry for our delay in the answers, I would double check the LPF2 filter behavior, but consider that all the filters introduces some delays and you should have to wait some ms to get a stable value each reading. Regards

[IDEngineer]

The bug we're seeing isn't a few milliseconds of delay. The bug manifests itself in two ways:

* The ODR setting changes to a slower value. The configuration registers do not indicate the change, and (re)writing the (same) proper values back into the configuration registers does not restore proper operation.

* The LSM6DS3 simply stops working. No more DRDY signals are generated no matter how long you wait (meaning you can wait HOURS without success) and in some cases even the SPI interface itself stops working (values cannot be written into the config registers, even WHO_AM_I cannot be read). Note this means that SW_RESET cannot be commanded via SPI, leaving a full power cycle as the only way to recover the chip.

I understand your point, that filters introduce delay, but that is not what is happening. There is a bug in the LSM6DS3, and our research suggests it is related to the workload caused by enabling LPF2 and its related filter chain. Since we disabled LPF2 and its filter chain, we have not been able to reproduce the bug.

In our opinion, the LSM6DS3 should be treated as a bare IMU as if it did not contain LPF2 nor anything past it in the signal chain. LPF2 and all further filters should be forcefully disabled at startup if reliable operation is desired.

Thank you for responding, and I hope the information in this thread proves useful to customers trying to use the LSM6DS3 and to ST as they update the device to hopefully fix this bug.