LSM6DS3: Very weird SPI behavior

[IDEngineer]

I'm seeing some very odd behavior on the LSM6DS3. It works "most" of the time, but seems to randomly change its own settings from time to time. Before we get into that, though, I'd like to ask about the timing of INT1 when driven by the DRDY signal.

In section 4.3, page 37, the appnote says:

That's pretty explicit: DRDY should be deasserted when register 0x29 is read. At the bottom of this figure you can see that it illustrates the trailing edge of DRDY at the *end* of the X axis data transfer, which makes sense because X's data is in registers 0x28 and 0x29.

Now look at what the LSM6DS3 actually does on a scope:

The bottom trace is SCL (not MOSI), so you can see the individual clock pulses. The red arrow shows how INT1, which is being driven by DRDY (INT1_CTRL/0x0D = 0x01), deasserts not at the end of the X axis data, but between the two bytes of X axis data. This directly contradicts the appnote figure above. Is this behavior controlled by a flag somewhere?

The answer to this question may answer another problem I'm having with the LSM6DS3. If it does not, I'll post that question next. But I'll try to keep the forum decluttered a bit until we find out if this answer covers both questions.

Thanks in advance for any assistance!

[Eleon BORLINI]

Hi, did you set the DRDY function in the right way? Which is your INT1_CTRL configuration? E.g. keep care of the (DRDY mask functionality). Regards

[IDEngineer]

Yes, DRDY was always set properly. The question was one of timing... what the appnote says is NOT what actually happens, as my original post above illustrates. However, extensive testing has shown that INT1 does work - just not as the appnote describes - and we have been able to make progress.

We still have trouble with the LSM6DS3's SPI interface locking up once in a while, requiring a power cycle to recover. The pin-compatible Bosch-Sensortec BMI160 does not suffer from that problem. That's a very serious bug in your LSM6DS3. Is anyone working on that?

[Eleon BORLINI]

​But at which Vdd / VddIO are you working? From the oscilloscope it seems you are at 5V... Regards

[IDEngineer]

The LSM6DS3 is running on 2V5 for both Vdd and VddIO. The signals on the scope are measured at the microcontroller, which is a 5V0 part. The signals are properly translated in both directions between the two components.

[Eleon BORLINI]

​Please be sure of the integrity of the signal that passes through the voltage translators, especially if they are bidirectional. Regards

[IDEngineer]

They are not bidirectional. This is a four-wire SPI interface, so none of the four signals are bidirectional. The signals at the LSM6DS3's pins are just as clean as those in the scope screenshot above. I can take a screenshot of the 2V5-level signals at the chip's pins if you like, but I promise they're nice and clean.

I've documented this SPI lockup bug in the LSM6DS3 extensively in another thread on this forum. Please read that for plenty of additional information. It may be related to what appears to be a firmware problem in the chip that occurs when the digital filters are enabled. It's all there in that other thread.

Again, the BMI160 does not appear to suffer from this bug. We've been testing both parts for calendar weeks and hundreds of hours of operation and the LSM6DS3 is consistent in having the bug while the BMI160, on the same PCB in the same conditions, does not. It follows the LSM6DS3. We'd love to use your part but at this point it doesn't appear reliable enough.