cancel
Showing results for 
Search instead for 
Did you mean: 

MLC embedded on LSM6DSOX gets stuck and only works on power on reset, with software reset it remained in same stuck case.

GSing.9
Associate II

MLC was working and suddenly stopped working , checked all the registers related to MLC and all the writes and read were happening properly.

Even tested accelerometer data in the same state and it was also working fine.

My device gets powered on using coin cell battery and after draining out the power , MLC started working (power dissipation in this scenario was much high than the normal scenario)

27 REPLIES 27


_legacyfs_online_stmicro_images_0693W00000bjgXtQAI.png 

Attaching for reference

And this is when the module ideally works


_legacyfs_online_stmicro_images_0693W00000bjgctQAA.png

the power consumption depends on both accelerometer and gyroscope ODR, and the MLC algorithm consumes power too.

it is strange that it does not return to lower levels when disabling MLC, but are the ODR at 0?

Niccolò

ODR for the accel is 104Hz and gyro is OFF.

From the datasheet what I read is MLC shouldn`t be taking more than 15uA with every decision tree, and I have only one decision tree used.

This actually is causing a lot of issues. Is there some state of MLC which can cause this issue, because we have checked on bare metal integration too (without RTOS) and the issue was same.

are you sure it is the sensor that consumes so much?

could it be something else?

Niccolò

I have debugged on this case and conclude that the only sensor that`s consuming this high current is lsm6dsox.

You haven`t observed this behavior before?

Hi @niccolò @Federica Bossi 

I have checked the MLC state when the module stops giving the desired output( MLC stuck at 0 state, decision tree not giving output), MLC is enabled but the MLC state checks are showing zeros (register read of 0x1A and 0x38).

I have again tried to reflash so that the MLC gets booted (boot enable on 0x12 register) and should start again but its not happening, it remains in that state.

What kind of memory content gets booted up while doing the BOOT operation (boot enable on 0x12 register), because on doing so MLC_ENABLE pin should go to default value 0 but its not.

One observation I had was that I am using lsm6dsox_pedo_debounce_steps_set a lot in my code to change the debounce count at specific intervals. In the function lsm6dsox_pedo_debounce_steps_set , there is lsm6dsox_ln_pg_write_byte function too, which is writing to specific pages of the module. Is it possible that these writes could be causing to overwrite the MLC config written by the UNICO generated header file.

Do let us know, what kind of debug and any suggestion to come out of this scenario.