Hi,
We are developing with the LSM6DSO32 in an application that experiences large shocks and during the shock we have found that the FIFO will contain a new timestamp and ODRCHG tag that is unexpected. A single timestamp and ODRCHG tag is consistent with initial setup of the sensor, but we are not doing any of this at the moment of impact. This has led us to believe that it is likely that there is some sort of reset happening at the time of impact. The unexpected FIFO tags happen both with and without the software compression feature enabled.
The above speculation, along with the fact that the other registers on the LSM6DSO32 are not reset, the readings of the accel and gyro look more or less correct, and it is aligned with impact led us to think it could be partially resetting the oscillation of the gyro which is likely used as the clock source. To test this, we disabled the gyroscope, and the timestamps are not reset at impact in this case. This is the only case we were able to find where the timestamp did not reset.
This leads us to two questions:
1. Is this a known issue with resetting the software core of the FIFO, and if it is resetting could this also cause a state reset in the Finite State Machines? We have observed some behaviour that leads us to believe the FSM state is being reset in the same way.
2. Is there a way to force the internal clock source of the LSM6DSO32 to be a relaxation oscillator (or whatever is used when the gyro is not enabled) rather than the gyro? We have seen this with other sensors such as the ICM-20649.
Attached is a UCF file that contains the register configuration we are using when we see the timestamp reset along with the raw bytes out of the FIFO, the FIFO data after parsing, and an image showing what we are talking about.
Thanks
