LSM6DSL on IKS01A2 board won't put gyro data into the FIFO

[Michael Moon]

Posted on February 23, 2017 at 08:04

Hi all,

I'm playing with the LSM6DSL sensor on the IKS01A2 board.

I'm trying to use the FIFO to record and buffer accelerometer and gyro data.

The accelerometer works fine and reading the gyro registers directly gives sensible data, however the gyro data in the FIFO for all 3 axes is *always* 0x7FFF (ie MAX_INT for int16_t).

I have scoured the datasheet and the LSM6DSM application note and can't find any indication of why this might be happening.

I've tried a huge amount of various settings, with no difference in outcome, currently using:

X_ODR = G_ODR = FIFO_ODR = 416Hz

Decimation = 1 (no decimation) for both accelerometer and gyro.

Typical FIFO readout looks something like this:

...

Got pattern    0 value 32767 (0x7fff) from FIFO with    6 words (empty=0 smartfull=0 overrun=0 watermark=0)

Got pattern    1 value 32767 (0x7fff) from FIFO with    5 words (empty=0 smartfull=0 overrun=0 watermark=0)

Got pattern    2 value 32767 (0x7fff) from FIFO with    4 words (empty=0 smartfull=0 overrun=0 watermark=0)

Got pattern    3 value 64348 (0xfb5c) from FIFO with    3 words (empty=0 smartfull=0 overrun=0 watermark=0)Got pattern    4 value  812 (0x032c) from FIFO with    2 words (empty=0 smartfull=0 overrun=0 watermark=0)Got pattern    5 value 17048 (0x4298) from FIFO with    1 words (empty=0 smartfull=0 overrun=0 watermark=0)Last packet:    0x7fff    (Gx: 286.7112 °/s)    0x7fff    (Gy: 286.7112 °/s)    0x7fff    (Gz: 286.7112 °/s)    0xfb5c    (Xx: -0.0724 G)    0x032c    (Xy: 0.0495 G)    0x4298    (Xz: 1.0399 G)X_FS 2.0000G G_FS 245.0000°/sG_direct: -1.067°/s -2.406°/s 1.566°/s

[Petr S]

Posted on February 23, 2017 at 09:54

Hello Michael,

please refer to the 'LSM6DSL_FIFODecimation' example code in the

X-CUBE-MEMS-XT1 (

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-software/x-cube-mems-xt1.html

) package suitable for NUCLEO-F401RE and NUCLEO-L476RG boards. You can compare your settings with the settings in correctly working example.

Thank you and best regards,

Petr

[Michael Moon]

Posted on February 23, 2017 at 12:01

It seems to be caused by setting INACT_EN to anything other than 0x00 (inactivity disabled) or 0x01 (leave gyro alone)

The datasheet says that wakeup will re-activate the gyro but it appears that it wakes up in such a way that it can no longer feed the FIFO.

So far, the only way I've found to restore normal functionality (after setting INACT_EN > 1) is to do either a powercycle, or a system+memory reset (write 0x81 to CTRL3_C). A system reset without memory reset doesn't help.

Presumably the idle mode is flipping some flag somewhere that's upsetting the gyro? Perhaps I'll have to dump all the registers and diff them to find out what's happening tomorrow.

[Michael Moon]

Posted on February 24, 2017 at 08:12

Gyro Working LSM6DSL Register Map Dump:

 0x0000    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0x09 0x00 0x24 0x00 0x00 0x28 0x00 0x6a 0x0010    0x40 0x40 0x44 0x00 0x00 0x00 0x00 0x00 0xe0 0x00 0x00 0x10 0x00 0x20 0x07 0xc1 0x0020    0x7c 0xf9 0x5c 0x00 0x05 0xff 0xbf 0x00 0x47 0xfd 0x38 0x01 0x79 0x43 0x00 0x00 0x0030    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe0 0x04 0x00 0xf3 0x01 0x0040    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0050    0x00 0x00 0x00 0x00 0x84 0x84 0x00 0x00 0xae 0xae 0x06 0x06 0x00 0x00 0x00 0x00 0x0060    0x00 0x00 0x00 0x00 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0070    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Gyro Broken LSM6DSL Register Map Dump:

 0x0000    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0x09 0x00 0x24 0x00 0x00 0x28 0x00 0x6a 0x0010    0x40 0x40 0x44 0x00 0x00 0x00 0x00 0x00 0xe0 0x00 0x00 0x10 0x00 0x20 0x05 0xc1 0x0020    0x8c 0xf9 0x62 0x00 0x04 0xff 0xc4 0x00 0x19 0xfd 0x61 0x01 0xea 0x42 0x00 0x00 0x0030    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x94 0x02 0x00 0x00 0xff 0x7f 0x0040    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0050    0x00 0x00 0x00 0x00 0x84 0x84 0x00 0x00 0xce 0xce 0x06 0x06 0x00 0x00 0x00 0x00 0x0060    0x00 0x00 0x00 0x00 0x00 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0070    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

As far as I can tell, the only differences are values expected to change from one dump to the next, and TAP_CFG (0x58) which is 0xAE in the working dump and 0xCE in the broken dump.

Note that at 0x3E-0x3F in the 'bad' dump, the described issue is visible - with INACT_EN > 1, the Gyro packet in the FIFO reads as 0x7FFF, yet the various OUT_G registers (0x22-0x27) read just fine in both dumps.

In case it matters, these dumps were generated by reading 8 lots of 16 byte blocks, relying on auto-advance (0x12=0x44 / CTRL3_C:IF_INC=1) which seems to turn up some strange numbers occasionally - eg addresses 0x54, 0x55 (values don't make sense), 0x59 (seems to be a repeat of 0x58 as value doesn't make sense), 0x65 (listed in datasheet as reserved address, but reads non-zero and changes every time it's read)