IKS01A2板上的LSM6DSL不会将陀螺仪数据放入FIFO

你好迈克尔，
请参阅中的示例代码
 （
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
）适用于NUCLEO-F401RE和NUCLEO-L476RG板的封装。您可以将设置与正确工作示例中的设置进行比较。
感谢你并致以真诚的问候，
 
切赫



以下为原文




Hello Michael,
please refer to the '' example code in the
(
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

这似乎是由于将INACT_EN设置为0x00（禁用不活动）或0x01（仅保留陀螺仪）以外的任何内容
数据表说唤醒将重新激活陀螺仪，但它似乎以这样一种方式唤醒，它不能再为FIFO供电。
到目前为止，我发现恢复正常功能的唯一方法（在设置INACT_EN＆gt; 1之后）是执行powercycle或系统+内存重置（将0x81写入CTRL3_C）。没有存储器复位的系统复位没有帮助。
据推测，空闲模式正在翻转一些让陀螺仪感到不安的旗帜？也许我必须转储所有寄存器并将它们区分开来以找出明天发生的事情。



以下为原文




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.

陀螺工作LSM6DSL寄存器地图转储：
 
 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 0x00Gyro Broken LSM6DSL寄存器映射转储：
 
 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 0x00据我所知，唯一的区别是预期会从一个转储更改为下一个转储的值，而TAP_CFG（0x58）在工作转储中为0xAE和损坏的转储中的0xCE。
请注意，在“坏”转储中的0x3E-0x3F处，所描述的问题是可见的 - 使用INACT_EN＆gt; 1，FIFO中的Gyro数据包读取为0x7FFF，但各个OUT_G寄存器（0x22-0x27）在两个转储中读取都很好。
如果重要的话，这些转储是通过读取8个16字节块来生成的，依赖于自动前进（0x12 = 0x44 / CTRL3_C：IF_INC = 1），这似乎偶尔会出现一些奇怪的数字 - 例如地址0x54,0x55（值没有意义），0x59（似乎是0x58的重复，因为值没有意义），0x65（在数据表中列为保留地址，但读取非零并在每次读取时更改）



以下为原文




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 0x00Gyro 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 0x00As 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)