lsm6dsv320x WHO_AM_i

[fk]

We're looking to use the lsm6dsv320x in our product. I'm using this senser on the on the STEVAL-MKI247A adapter board for testing. We're currently in development using the adapter board with the Nordic nRF52840DK board. I'm having issues with getting the correct value from the WHO_AM_I with certain SPI pin configurations on the nRF52840DK. I can only get one SPI configuration to output the correct value of 0x73 which is SPI1. If I try change the pins or use one of the other SPI's available on the 52840, I consistently get a value of 0x64. Does that value mean anything to anyone? I've tried lowering the frequency to 500kHz, tried all four of SPI modes, I've tried performing a reset using the FUNC_CFG_ACCESS and CTRL3 registers before reading the WHO_AM_I register, but I still get the value of 0x64 except with the one configuration mentioned. I'm using the ST fsm_example for this test. We would like to change the SPI pins as the we want to use the smaller package of the nRF52840 which doesn't have some of the default pins for this SPI! bus. I've looked at the waveforms on an analyzer and there seems to be plenty of setup and hold with the address and data. Any significance to the value of 0x64?

[TDK]

 

You're reading register address 0x8F. The WHO_AM_I register is register address 0x0F.

https://www.st.com/resource/en/application_note/an6119-lsm6dsv320x-6axis-imu-with-ai-highg-accelerometer-and-embedded-sensor-fusion-for-highend-applications-car-crash-detection-stmicroelectronics.pdf

 

 

[fk]

 

[Andrew Neil]

---

@fk wrote:

I've looked at the waveforms on an analyzer 

---

Does it show any difference between "working" and "non-working" cases?

 

PS:

Check also with an oscilloscope for any issues in the analogue domain.

Have you checked carefully that the Nordic DK doesn't have anything attached to the "non-working" pins?

[fk]

The difference between the waveforms is that it accurately shows the data value that is being received by the 52840. 0x64 which is the incorrect value and 0x73 which is the correct value. So, the waveforms are accurately showing the incorrect/correct data being produced by the lsm6dsv320x.

[TDK]

How confident are you that it's a lsm6dsv320x chip? Does the marking on top match up? Apart from the WHO_AM_I register, does the chip behave as expected? Could just be a bad datasheet value.

 

It looks like the STEVAL-MKI247A board comes with a different chip (LSM6DSV80X). You replaced it with this one?

STEVAL-MKI247A - LSM6DSV80X adapter board for a standard DIL24 socket - STMicroelectronics

 

Doubt any of that solves it, but I'm out of ideas.

[fk]

Thanks for trying but yes, I have tried another module with the same result. On the 528140, the module works in one pin configuration, but not in the other pin configurations. It also works as expected using another Nordic kit, the nRF54L15. So, it seems to be something with the 54840, but I have no idea why the sensor puts out this incorrect value while the communication looks clean.

[gabriele33]

Hello,

I have the same board (steval mkI247AA) and I noticed the same exact issue.

I am using a nrf2340 dk as main board and the steval is on a breadboard and I connected the dk with the breadboard using jump wires.

I transmit 0x8f and I receive 0x64 on the second received byte. If I make a longer connection SDO -> MISO (i.e. double jumper wire), I read 0x73! And the waveform is completely different looking at the oscilloscope, it's a clear 0x64 and a clear 0x73. It's like the chip is changing is output.

I tried both with pull up enabled and disabled on the mcu side.

I don't know what else I can try.

[Andrew Neil]

---

@gabriele33 wrote:

the steval is on a breadboard and I connected the dk with the breadboard using jump wires..

---

So loads of potential there for dodgy connections!

Can you try with soldered connections; eg, via an X-NUCLEO-IKS4A1 or an Arduino prototyping shield?

 

---

@gabriele33 wrote:

the waveform is completely different looking at the oscilloscope, .

---

Please post oscilloscope traces of both cases.

(If at all possible, Please use the scope's screen capture, rather than photographing the screen)

[gabriele33]

Hello,

thanks for your reply. I attached two screenshots with the two cases, I am still with two jumper wires. I'll try with soldered connections. Yellow CS, cyan CLK, violet MOSI and blue MISO.

[Andrew Neil]

single_wire_zoomed.png:

double_wire_zoomed.png:

 

What's the significance of "single wire" and "double wire" ?

[gabriele33]

Yep sorry, single wire is a single jump wire between the dk and the steval. double wire is a double jump wire connected in series between dk and steval to have a longer connection. The difference is only on the SDO/MISO line.

I want to show you a new screenshot. This time I removed the "clock stretching" changing how I call spi_transceive in zephyr os (it was tx 1 byte and rx 2 bytes now it is both 2 bytes, I don't know why in the previous configuration there was a clock stretching). I removed the pull up on the mcu side.

The curios thing is that I have another breadboard with another steval (iis2dh) and it works fine connected on the same bus in place of this one we are discussing.

[rv_08]

I am also facing exactly same issue with mk1251 kit used with three different st controllers .

[tjstone14]

I have also seen this issue intermittently with the lsm6dsv320x (STEVAL-MKI251A) connected via jumper wires to a nRF54L15 dev kit.  I think it is a timing issue.  If I read the WHO_AM_I register immediately at power on, I get a 0x73.  However, if I delay slightly (~20 msec) before reading, I get 0x64.

[tjstone14]

I am able to work around the issue by switching from SPI to I2C. 

[TDK]

That is so weird. Thanks for posting the video.