LSM6DSO issues with SPI

[KShar.4]

Hi ST community,

Currently we are trying to use the LSM6DSO (6 Axis MEMS sensor) in our project.

We were able to successfully test the LSM9DS1 (9 Axis MEMS sensor) using the ST Adapter board STEVAL-MKI159V1 and we had no issues communicating with it and were also getting very good results.

For this adapter board, we connected:

-Vdd = 3.3v

-VddIO = 3.3v

-SDO = SPI MISO

-SDA = SPI MOSI

-SCL = SPI clock

-CS = SPI chip select (Negated)

And ofcourse the Ground pin as well

And whenever we send the command 0x8F to read the WHO_AM_I register (Register address 0x0F) via SPI we get the correct response back which was 0x68 from the accelerometer/gyroscope module and 0x3D from the magnetometer. And these are the correct values that are described the LSM9DS1 datasheet.

Now we trying to communicate with the LSM6DSO (using ST Adapter board STEVAL-MKI196V1), by doing the same exact connections like the LSM9DS1.

-Vdd = 3.3v

-VddIO = 3.3v

-SDO = SPI MISO

-SDA = SPI MOSI

-SCL = SPI clock

-CS = SPI chip select (Negated)

And the Ground pin as well

But whenever we send the SPI command 0x8F to read the WHO_AM_I register (register address: 0x0F) we always receive back 0x50 - we attached a digital analyzer screenshot. According to the LSM6DSO datasheet the expected result should be 0x6C (and not 0x50)

  

Now we tested the WHO_AM_I command on the following boards:

1- STEVAL-MKI197V1 (based on the LSM6DSO sensor)

2-STEVAL-MKI215V1 (based on the LSM6DSO32 sensor)

3-STEVA:-MKI196V1 (based on the LSM6DSO sensor)

And all of these 3 boards are returning 0x50 when we send the WHO_AM_I command. Knowing that the expected result should be 0x6C.

One thing to mention is: We did a similar test using the LSM6DS3 (using the STEVAL-MKI160V1 adapter board) and we were getting the correct value 0x69 for the WHO_AM_I command.

We also noticed, that on the forum, there was another colleague who also had a similar issue with this sensor.

Link to the thread: https://community.st.com/s/question/0D50X0000AFqjrRSQR/lsm6dso-spi-communication-problem

For him, it seems that he had a different voltages for Vdd and VddIO. But in our case we are having 3.3v for both Vdd and VddIO. And our microcontroller DIO voltages are at 3.3v.

We wanted to know, if we are missing something to communicate via SPI with the LSM6DSO and the LSM6DSO32? If not, then what is the issue in this case.

Thank you!

[Eleon BORLINI]

hI @KShar.4​ ,

this looks strange... Could you please share the configuration of the other pins? Are you following the indications of the LSM6DSO datasheet p.? (especially for the SDx and SCx that have to be connected to Vdd or GND?)

Since you are using the STEVAL adapter, the only further suggestion could be to un-solder the resistors R1 and R7, leaving these pads floating.

 

-Eleon

[KShar.4]

Thanks @Eleon BORLINI​ for your fast response.

Attached is a picture of the STEVAL-MKI196V1 board that we are using. We didn't move the Resistors R3, R7, R1 & R5. This is the default configuration that we received them at.

The pin configuration was:

-Vdd = 3.3v

-VddIO = 3.3v

-SDO = SPI MISO

-SDA = SPI MOSI

-SCL = SPI clock

-CS = SPI chip select (Negated)

And the rest of the pins were floating. That means SCx and SDx pins were also floating.

As you suggested, we also tried connecting SCx & SDx to:

a- Ground

b- Vdd (3.3v) in our case

But in both cases we still get 0x50 for the WHO_AM_I command.

We also tested this on the STEVAL-MKI197V1 (connecting both SCx & SDx to GND - Testcase 1 and to Vdd Testcase 2) and it was also repling back with 0x50 to the WHO_AM_I command.

Regarding unsoldering R1 & R7 which are used for the OCS & OSDO (consecutively), these 2 pins are left floating. So even if we were to unsolder them, we will still have the same affect since we have the pins already floating. Or are we missing something?

One thing to add as well is, we tried the STEVAL-MKI196V1 on the ST MEMS motherboard STEVAL-MKI109V3 with the Unico software. And we are getting an error result when we try to connect with the Unico software. Stating that the board does not respond. We are not sure if the software means the motherboard or the sensor board (Attached picture below).

This is not the case for the STEVAL-MKI159V1 as we are able to connect easily with this board.

Any suggestions for what is missing? We really want to use the ST sensors for our product.

Thank you in advance!

[Eleon BORLINI]

Hi @KShar.4​ ,

>> One thing to add as well is, we tried the STEVAL-MKI196V1 on the ST MEMS motherboard STEVAL-MKI109V3 with the Unico software. And we are getting an error result when we try to connect with the Unico software. 

This is very strange... the Unico version and the FW are updated. Can you please try to plug the STEVAL-MKI196V1 on the STEVAL-MKI109V3 in the reverse direction? And can you please send me (more zoomed) a picture of the top marking of the device, in order to check if it is effectively an LSM6DSO device? I would also ask you if you have tried more than one STEVAL-MKI196V1...

In the other case, where you are not using the STEVAL-MKI109V3, please check the datasheet p. 7 and 8 for the pin initialization values.

-Eleon

[KShar.4]

Hi @Eleon BORLINI​ ,

Thank you for your response! And I am more than certain that with your assistance we will understand the root cause of this behavior.

In regards to plugging the STEVAL-MKI196V1 in the opposite direction on the ST MEMS moetherboard.

We originally connected JP1 to JP1 and JP2 to JP2 (sensor to motherboard). Now, as you suggested, we connected the JP1 to JP2 (and vice versa) but still got the same error from Unico

 

So, we took a picture with our microscope (tried to have the perfect lighting to reduce reflection to the camera lens) for the STEVAL-MKI196V1 & STEVAL-MKI197V1.

Below is the zoomed picture for the STEVAL-MKI196V1

As you can see from the picture, the device part number is S0 - 919.

 

And below is the zoomed picture from the STEVAL-MKI197V1

As you can see from the picture, the device part number is S4 - 912.

 

On the other hand, the datasheet doesn't state the part number that should be written on the LGA package. 

Honestly, we currently have one board, but if you think it makes sense to order another 2 we wouldn't have a problem ordering more STEVAL-MKI196V1

We will make sure, that when we are not using the STEVAL-MKI109V3 that we adhere to pin initialization values on p.7 and p.8

But are these part numbers correct?

Merci Beaucoup!

[Eleon BORLINI]

Hi @KShar.4​ 

Part numbers seems OK

I see that you don't have installed the last version of the STEVAL-MKI109V3 firmware, the ProfiMEMSToolV3.7.35.bin. You can find it in the folder \FIRMWARE\ProfiMEMSTool board of the last Unico package (the 9.8.9 for Windows) you should have already downloaded. You can flash it on the using the STM32CubeProgrammer, and I attach below a tutorial example for another board, which is however similar to the ProfiMEMS for this purpose: the only change is the DFU mode setting. To enter DFU mode for the ProfiMEMS board:

a. press buttons BT3 (Reset) and BT2 together

b. first release BT3 and then release BT2

Let me please know if this can be of any help.

-Eleon

[KShar.4]

HI @Eleon BORLINI​ 

Thank you for your response!

A quick update from my end, I was able to have (for a short period of time) SPI communication with the sensor and was able to read the WHO_AM_I register. But then stops. 

Here was my test scenario:

1- Connected the following pins:

-Vdd = 3.3v

-VddIO = 3.3v

-SDO = SPI MISO

-SDA = SPI MOSI

-SCL = SPI clock

-CS = SPI chip select (Negated)

-SCx = GND

-SDx = GND

-GND pin = GND

2- When I try to communicate with the sensor, I get the wrong response for the WHO_AM_I command. Wrong response was the 0x50

3- I disconnect the Vdd and VddIO and then I communicate with the SPI and able to recieve the WHO_AM_I register value 0x6C

But of course this doesn't last long, as the capacitors (C1 & C2) on the MKI197v1 will fully discharge. But they did function when they were discharging!

 

This gave us the indication that something is not right with the voltage levels. (Vdd and Vdd-IO)

So, we checked the development board that has our microcontroller, and we do see that Vdd_IO for the SPI pins are functioning at 3.3v (and not 1.8v).

We do know that chip manufacturers have different part numbers for different variants of a chip.

That is why, we would like to know if the sensor LSM6DSOX part number (S4 - 912) functions at 3.3v?

At the same time, we have also ordered extra dev boards to test with, they should be here within this week for us to test with them as well.

We will update the MKI109V3 and will keep you posted.

Merci Beaucoup!

[Eleon BORLINI]

Hi @KShar.4​ ,

if all the circuit voltages are coherent, I mean master I2C (application processor) and slave I2C (the DSO or DSOX IMU) are at Vdd and VddIO 3.3V, (or VddIO < Vdd), there should be no issue.

>> 3- I disconnect the Vdd and VddIO and then I communicate with the SPI and able to receive the WHO_AM_I register value 0x6C

It's not a safe condition to work, indeed. Are you meaning that you are able to read the correct WHO_AM_I while the decoupling capacitors are discharging, i.e. the Vdd is less than 3.3V? This is quite strange because a 100nF capacitor should not have long discharging time constants... Can you please check if you are facing this issue also with the (FW updated) MKI109V3 board, in order to exclude a chip issue? The ProfiMEMS works at 3.3V since it is the power level of the onboard STM32F4.

>> we would like to know if the sensor LSM6DSOX part number (S4 - 912) functions at 3.3v?

I confirm you both, i.e. the DSOX part number is indicated with S4 (912 means that the chip lot has been assembled and tested in 2019 wk12) and that the IMU works well at Vdd = VddIO = 3.3V.

>> At the same time, we have also ordered extra dev boards to test with, they should be here within this week for us to test with them as well.

We will update the MKI109V3 and will keep you posted.

I'll wait for your updates, thank you for your detailed reporting.

-Eleon

[TBern.2]

Hello I have joined this thread because I have a similar problem. Was there ever a resolution of this? Allow me to share my own situation

I have several little prototype boards for the LSM6DS3h, two are the off-brand "purple" ones, and two are the red "sparkfun" ones. I am connecting them to the STM32F 303 Nucleo board, to the SPI2 port

As usual I am trying to read WHO_AM_I as my test. In software (keil compiler) I can consistently read 0x40 from WHO_AM_I. I mean very consistently, thousands of reads in a row will return this value. When I put it on the scope. I can clearly see that the LSM chip is replying with a very clear 0x40. The waveform is crisp (this will happen at any SPI speed but i do testing at ~200khz so it shows up good on my ancient analog scope)

This is 3 different prototype boards. They all behave exactly the same, replying with 0x40. I have connected two channels of my scope to the clock and data lines, and gone over it with a careful eye to confirm that the waveforms are conforming (they are).

Now, 0x40 is actually the "beginning" of the correct reply of 0x69 (im not sure why the previous poster mentioned 0x68 and 0x6c but the datasheet clearly says 0x69). the first "1" bit of 0x69 is actually the bit located at 0x40.. ( 0x40= b0100 0000 , 0x69= b0101 1001) so the MSB and MSB-1 of the replies are the same, but then they diverge.

I should mention now that since I am using an analog scope with no memory, I have the STM32 chip programmed to read WHO_AM_I repeatedly 1000 times per second. This makes a solid trace on my scope composed of hundreds of separate trials superimposed.

I finally decided to do a bit of a sanity test, and I simply removed the MISO wire from the breadboard, so that the wire was ONLY connected to my scope probe, and not to the Nucleo board at all. Suddenly, I could see the correct value of 0x69! As soon as I plug the wire back into the Nucleo board (still scoping it), the response turns back to 0x40. This is actually how I noticed that the first two bits of 0x40 and 0x69 are the same. On the scope, the waveform for the first two bits looks exactly the same when the LSM replies 0x40, or when it replies 0x69, except in the former case, the LSM output transitions to "0" after the MSB-1 bit, and stays there. It transitions exactly on the correct clock edge as if it was actually meaning to output 0 values for MSB-2 onwards. The single bit of the 0x40 is exactly the correct width to be a single bit. The waveform is crisp and square as if by some logic it gave up after the first bit and decided to send the rest as 0.

I know the original person said that they were receiving 0x50 which is actually not part of the number 0x69 but I think it is possible their other SPI settings were not optimal because the waveform for 0x40 and 0x50 are the same (single pulse, just different length) and I was able to sometimes receive 0x50 in my DR if I had my CPOL or CPHA set wrong...

so ANYWAYS

I tried some ways of loading down the pin to see if i could get the same results. Connecting the MISO pin to other pins on the STM Nucleo board all resulted in the 0x40 reply. I tried it on a pin I specifically configured as a normal GPIO input (B6 I think), same 0x40 reply. Connecting it directly to ground or 3v3 with a 1k resistor, it still replies 0x69 as it should with 4mA drive capability. But when I connect the 1k resistor in series between MISO and the STM32f, it replies 0x40 again! So strange...

I settled on a resistor that was about 2.2k. At this value the LSM replies 0x69, and although the waveform is severely degraded on the STM32 side of the new MISO resistor, I can read the chip semi-reliably at 10mhz (although based on the waveform I would never send that to production)

So... what is going on here. Are these little breakout boards doing something fundamentally wrong? are we dealing with fake chips? bad batch? something weird about voltages? Oh yeah I am running it off of the 3.3v arduino connector pin on the Nucleo board, the whole system should be on the same 3.3v supply.

One other thing I should mention... I had used one of the "purple" boards in I2C mode on another project and that worked great, no problems, I even "overclocked" the I2C to 1Mhz and it worked fine. Same exact specimen that cannot do SPI properly..

We actually have a fully assembled prototype PCB on order with the LSM already connected directly to the STM chip on a single PCB, which is actually not our first time doing this, and it has always worked fine for us. Thats why this is confusing. This is not my first LSM project. Im really hoping that will "just work" and I can forget about these crappy little breakout boards altogether.. but its still frustrating that they dont work, I meant to save myself some time but I ended up just wasting it.

I suppose I can just limp by on my 2.2k resistor until I find out if our PCBs work

 

[KShar.4]

Hi @TBern.2​ ,

Sorry, I just got to see your message right now! Apologize for the late response!

So my issue was, the breakout pins were not that clean, that I didn't have a connection to the microcontroller. I don't remember which pins (but they were 2 in total). I had to clean them all and make sure everything is connected using a multimeter (shot circuit beep detection). After doing this, everything worked fine.

I hope this helps!

Let me know if this works for you!

[paul19]

I have a similar issue: my LSM6DSOX (from a STEVAL-MKI197V1) always returns 0x00 as WHOI_AM_I instead of 0x6C.

If I ignore this issue, though, it seems to work correctly, i.e. I seem to get reliable acceleration, gyro and temperature data (polling mode).

Connected pins:

-Vdd = 3.3v

-VddIO = 3.3v

-SDO = SPI MISO

-SDA = SPI MOSI

-SCL = SPI clock

-CS = SPI chip select (Negated)

-SCx = 3.3v

-SDx = 3.3v

-GND = ground

[TBern.2]

Your issue is a little better than mine, since for me the SPI bus did not work at all. The best I could tell from working on this before is that the SPI bus was glitching out for me because the transmission line was "bad" for some reason. you could try improving the connection (solder vs breadboard), adding termination resistors, or series resistors.

But based on your description it almost sounds like it might be some kind of software problem since it is strange to have one bad read at the very beginning on a SPI bus which is clocked by the master.. what happens if you try to read the same register twice? Maybe the bus is not initialized properly or something

[paul19]

Yes, you're absolutely right, it's a software problem. The SPI bus is not initialized properly. If I call __HAL_SPI_ENABLE() at the very beginning, it works perfectly. I'm currently investigating how this is possible, since my SPI init is supposed to be generated by STM32CubeMX...

UPDATE: my issue was due to a bad SPI setup, I forgot to set a pull-up on SPI SCK.

[jovijuan]

I know the thread is pretty old but I'm having a similar issue.

I'm trying to communicate with an LSMDSO on STEVAL-MKI196V1 and they always return 0x50 or 0x51 to the read of the WHO_AM_I register.

Connection is similar to many others:

-Vdd = 3.3v

-VddIO = 3.3v (tried also with 3.05V as the voltage in the microcontroller board is ~3.05V)

-SDO = SPI MISO

-SDA = SPI MOSI

-SCL = SPI clock

-CS = SPI chip select (Negated, 270kOhm pull-up)

-SCx = GND

-SDx = GND

-GND = GND

-OCS = floating

-OSDO = floating

The scope shows clean edges.

If I ignore the WHO_AM_I, I can configure the registers. I can configure resolution, frequency, interrupts, etc. To be honest, I have another issue as INT1 is triggered with accelerometer data, but when I try to check STATUS_REG, the flag XLDA is always 0, but that might be an issue with the configuration.

This is a capture of the logic analyzer in the WHO_AM_I register reading:

 

What I found weird is that this behavior is consistent when the supply is stable, but then I realized that if I turned off the LDO, VCC didn't really go to 0V due to leakage from logic analyzer and microcontroller, it stayed at ~2.4V and at that voltage, WHO_I_AM returns 0x6C!!!

The behavior is exactly the same on both STEVAL-MKI196V1 I have.

Is there any explanation for the error in the WHO_AM_I register???

[TBern.2]

IIRC my own problems went away when I switched to a PCB from a breadboard. You may want to look at the signal with a fast, calibrated scope to see how far it differs from an ideal square; if its gnarly your logic analyzer might see different bits than the ST part does anyways

Check out the thread here, and then the other thread it links to in the main question for some scope traces and further discussion

https://electronics.stackexchange.com/questions/33372/spi-bus-termination-considerations