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?

[rv_08]

It worked after opening the bridges SB36 and Sb38 over X Nucleo- IQS4A1A to avoid the conflict of two devices connected over I2c with same address of LSM6DSV320X but with different whoAmI. That's is why problem is only on I2C and not over SPI. See the Fedrcia Bossi reply on my other thread. Device is perfectly working now.

Solved: Inconsistent whoAMI address of LSM6dsv320x on eval... - STMicroelectronics Community

[mshioji]

[SOLVED] LSM6DSV320X SPI Communication Issue - Hardware Solution

Following up on my previous report about the SPI communication instability (the "touching SCK changes behavior" phenomenon):
Solution Found:
Adding series termination resistors resolved the issue.
Hardware modification:

100Ω series resistors on SCK, MOSI, MISO lines (between sensor and MCU)
10kΩ pull-down resistor on MISO line (sensor side, close to chip)

Test Environment:

Sensor: LSM6DSV320X (STEVAL-MKI251A evaluation board)
MCU: ESP32-S3 (Seeed XIAO ESP32S3)
Interface: SPI, Mode 1
Connection: ~50mm jumper wires between sensor and MCU

Results:

WHO_AM_I register reads correctly and consistently (0x73)
All registers read/write stable, including sensor data burst read
No more intermittent communication errors

Important Finding:
I had similar SPI communication issues with ISM330DHCX (another ST MEMS sensor) in a previous project. At that time, I gave up on it and used another company's chip. However, when I applied the same series termination solution to ISM330DHCX, it also resolved that issue. This suggests similar signal integrity requirements may exist across ST's MEMS sensor family.
Note on Component Values:
The 100Ω value worked for my specific setup (ESP32-S3, 50mm wires, direct connection). Optimal values may vary depending on:

MCU type and SPI driver characteristics
Wire length and PCB layout
Sensor board design

I don't have equipment to measure precise impedance matching or signal reflection, so these values should be considered a working example rather than universal recommendations.
Implementation:
Since I couldn't place components between MCU and sensor board in my final design, I modified the STEVAL-MKI251A evaluation board by soldering chip resistors directly on it (see attached pictures).
If you have space outside of the board, you can also try using axial resistors or similar components.

Since the evaluation board doesn't have resistor footprints for series termination, I had to solder chip resistors directly. Would be nice to have those pads in future revisions!


Request to ST:
Given that this issue appears across multiple sensor types and MCU platforms, could ST consider:

Documenting signal integrity requirements for various MCU types in datasheets?
Providing application notes with recommended termination values?
Testing with commonly used MCUs beyond STM32 evaluation kit?

Status:
My project prototype is now working stably with this solution.
Hope this helps others facing similar issues!