cancel
Showing results for 
Search instead for 
Did you mean: 

SW_RESET on lsm6dsv16x bit is never cleared

sneakyHulk
Associate

Dear Community,

I think I have encountered an uncommon problem. The SW_RESET bit in CTRL3 on the lsm6dsv16x does not change to 0 again. In https://www.st.com/resource/en/datasheet/lsm6dsv16x.pdf it states that after the software reset this bit is automatically cleared. Even after disconnecting the power and doing a reboot, also of the chip itself this bit wont change back to 0. I use https://github.com/STMicroelectronics/lsm6dsv16x-pid to communicate with the chip, and other things like reading who_am_i and so on work normally. But otherwise, I only get meaningless readings from the sensor. What can be done about this, especially the reset bit?

Thanks and greetings

1 ACCEPTED SOLUTION

Accepted Solutions

Thanks Federica Bossi, I managed to fix the issue. The problem was caused by using a Repeated Start condition during I²C reads instead of sending a Stop condition followed by a new Start condition. Because of this, all read operations were returning inconsistent and implausible data. After correcting the I²C transaction sequence, everything is now working perfectly. Thanks again for the support! Greetings.

View solution in original post

2 REPLIES 2
Federica Bossi
ST Employee

Hi @sneakyHulk ,

WHO_AM_I is read correctly, so basic I²C/SPI communication seems fine.
If the SW_RESET bit in CTRL3 never clears, the most likely causes are:

  • Wrong or incomplete write to CTRL3 (0x12)
  • Power or reset issue: for example, VDD/VDDIO not stable

What you could do:

  1. Minimal sequence: read CTRL3, write 0x01 to 0x12, wait >10 ms, read CTRL3 again and log the raw values. Without using the driver.
  2. Verify VDD and VDDIO levels and that the device is fully power‑cycled.
  3. Use a logic analyzer to confirm that register 0x12 is really written and read with the expected bytes.
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks Federica Bossi, I managed to fix the issue. The problem was caused by using a Repeated Start condition during I²C reads instead of sending a Stop condition followed by a new Start condition. Because of this, all read operations were returning inconsistent and implausible data. After correcting the I²C transaction sequence, everything is now working perfectly. Thanks again for the support! Greetings.