Skip to main content
Visitor II
March 11, 2021
Solved

Problems with LSM6DSOX basic operation

  • March 11, 2021
  • 7 replies
  • 7549 views

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

    This topic has been closed for replies.
    Best answer by RLee.4

    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.

    7 replies

    RLee.4AuthorAnswer
    Visitor II
    March 11, 2021

    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.

    ST Employee
    March 12, 2021

    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.4Author
    Visitor II
    March 12, 2021

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

    ST Employee
    March 16, 2021

    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.4Author
    Visitor II
    March 16, 2021

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

    Note on here that SDx and SCx are floating pins.

    RLee.4Author
    Visitor II
    March 16, 2021

    0693W000008x3MKQAY.png

    ST Employee
    March 17, 2021

    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.4Author
    Visitor II
    March 17, 2021

    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