LSM6DSO No response on MISO line.

[DJack.8]

I am trying to read the "Who am I" register of a LSM6DSO. I get no response on the MISO line. I suspect I am not configuring the IMU correctly. I am using a Nucleo-L031K6 connected to a MKI196V1. I attached the code. Am I missing something in the configuration for SPI? I have the data sheet but still resort to too much guessing. Am I missing a document or code resource? Any help or code examples is appreciated.

Thanks,

Doug

[Eleon BORLINI]

Hi @DJack.8​ ,

the WHO_AM_I register doesn't need any device configuration to be read, only powering on the device and correctly setting the SPI. So the issue should be related to the STM32L0 settings.

You might start with checking the existing examples for configuring the SPI on the L0 MCU family (STM32CubeL0 package), and check the SPI peripheral settings. You can also have a look to the FP-SNS-ALLMEMS1 function pack on about how to integrate the LSM6DSO drivers inside; you can also use, for example, the Github C drivers here.

-Eleon

[DJack.8]

Hi Eleon,

Thanks for the reply. It was my understanding that the LSM6DSO defaulted to I2C. This would mean the MISO line was not active from the sensor until switched to SPI. Am I wrong here? I'll look at the examples again. They didn't help me much the first time. Examples of simple SPI read and writes to sensor registers would be a great resource. I'd pay for such a thing.

[Eleon BORLINI]

Hi @DJack.8​ ,

but are you able to correctly communicating with the device via I2C, and not with SPI?

This might be only an issue of LSM6DSO device pin configuration. You might try with the I2C_disable bit of the CTRL4_C (13h) being set to "1", in order to disable the I²C block.

By the way, I note down your documentation request.

-Eleon

[S.Ma]

Read carefully the datasheet. Is the chip booting in I3C mode? Is it configured as SPI 3 wire interface?

[ejr2224]

We have also seen a problem reading the WHO_AM_I register using SPI. After a SW_RESET we read the WHO_AM_I register and rarely it comes back 0x00 instead of 0x6C. The rarely part has made it difficult to troubleshoot. We had one chip that always failed so we disabled I2C in CTRL4_C. That appeared to fix the problem. Unfortunately, removing disable I2C in CTRL4 did not bring the problem back! The SW_RESET defaults to I2C enabled so we do not feel good about this "fixing" the problem.