1 ACCEPTED SOLUTION
Accepted Solutions
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
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!
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!
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!
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
