cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with LSM6DSOX basic operation

RLee.4
Associate III

I've got something really screwy going on with the LSM6DSOX chip. I've got it hooked up in simple form using 4 wire SPI mode 0 and 3. I can talk to the chip just fine. Read and write no problem.

The first problem is that I want to do a SW reset. Setting the SW_RESET bit in CTRL3 easy enough but the part a) never resets as far as I can tell and b) never clears that bit, ever. Until I write that as 0.

The second problem is that I can't get the part to actually start taking accelerometer samples. Because I can't get the part to reset to factory via SW reset, I just wrote factory defaults to all the registers and set it that way. From there I used the following simplistic approach from an ST App Note:

  1. Write INT1_CTRL = 01h// Acc data-ready interrupt on INT1
  2. Write CTRL1_XL = 60h// Acc = 417 Hz (High-Performance mode)

I never see any bits set in STATUS_REG from this or an INT1 signal of any kind

What can I possibly be doing wrong here? I've tried much more complex stuff than this configuring the filter paths and all kinds of things... I never see the data ready..

1 ACCEPTED SOLUTION

Accepted Solutions
RLee.4
Associate III

Interesting. It appears that you can put this chip into a mode where it basically ignores the outside world.

Because of a firmware bug in code here, at one point the firmware was talking to a different chip while having CS asserted on this chip meaning that random things were being mostly written to this chip. No idea what.

This particular board I'm on doesn't have an easy way to do a power reset so with this chip in some screwy mode, it wasn't paying attention to the SW_RESET or most anything else either. You could write to the WHO_AM_I register and it wouldn't take that but would read correctly but otherwise, a lot of registers were giving what should be nonsense values.

Once I managed to power cycle this chip, it started working.

This is somewhat disturbing in that you actually can put this in a mode where the only way out is a power cycle.

View solution in original post

8 REPLIES 8
RLee.4
Associate III

Interesting. It appears that you can put this chip into a mode where it basically ignores the outside world.

Because of a firmware bug in code here, at one point the firmware was talking to a different chip while having CS asserted on this chip meaning that random things were being mostly written to this chip. No idea what.

This particular board I'm on doesn't have an easy way to do a power reset so with this chip in some screwy mode, it wasn't paying attention to the SW_RESET or most anything else either. You could write to the WHO_AM_I register and it wouldn't take that but would read correctly but otherwise, a lot of registers were giving what should be nonsense values.

Once I managed to power cycle this chip, it started working.

This is somewhat disturbing in that you actually can put this in a mode where the only way out is a power cycle.

Eleon BORLINI
ST Employee

Hi @RLee.4​ ,

glad to see you solved the issue.

As described in the LSM6DSOX datasheet p.18, the device is compatible with SPI modes 0 and 3. So you could find some issue in the Mode 1 case (when CPHA=1).

-Eleon

RLee.4
Associate III

@Eleon BORLINI​ Looking back on this, I see that I worded this a little ambiguously.. I've got this chip working in SPI mode 0 (and lately in 3) over 4 wire SPI and have been using it in accelerometer mode 1 (not connected to outside peripherals).

The way it was written suggested SPI mode 1 which would cause all kinds of havoc I should think.

The interesting thing to me is that after feeding the chip garbage (which SPI mode 1 would also do), you can get the thing into a state that you can't get back out of except via power reset. It completely ignores the SW_RESET command.

Hi @RLee.4​ ,

that's a strange behavior... I'm wondering whether it might be related to the device pin configuration... I mean some pins not properly set.

Is your schematic compliant with the datasheet instructions (p.39) or with the STEVAL connections?

0693W000008x1q8QAA.png 

-Eleon

RLee.4
Associate III

It is possible that we've got something like that happening here.... Yes....

Note on here that SDx and SCx are floating pins.

RLee.4
Associate III

0693W000008x3MKQAY.png

Eleon BORLINI
ST Employee

Hi @RLee.4​ ,

Please note that the VddIO upper limit is 3.6V (datasheet p.13), while you are reporting 5.5V (that is also out of the absolute maximum ratings of 4.8V, datasheet p.16).

About the SDx and SCx left floating, the datasheet states that you have to connect them to VDDIO or GND (datasheet p.8)...

Could you try to check if you are still facing issues in this configuration? (I believe you could use the TP8 and TP9 test point to fixt the pins to one of the above voltages)

-Eleon

RLee.4
Associate III

we're running that system at 3.3V so no worries there. The TPs on there make it easier to tie to something and I'll do that. Interestingly enough I don't see this problem a lot so the thing must be mostly stable with them floating.... I haven't run into the problem since I power reset it so I'm thinking this isn't happening with any regularity (a good but frustrating thing)...

Thanx