How to distinguish LSM6DSOX and LSM6DSO in software? - they have the same WHOAMI register value

BWatsz · ‎2022-06-14

I have a 2nd prototype board just manufactured and the LSM6DSOX seems to behaving differently, particularly after loading the Unico generated UCF data. I am wondering if a LSM6DSO was mounted instead of the LSM6DSOX - they have the same WHOAMI register value: 0x6C (ref DS12140 section 9.11 and DS12814 section 9.14).

The designations on the physical devices are v hard to read, but the original device may have '948' and the other '848'. The datasheets do not indicate any device markings.

BTW - is there a full list of WHOAMI register values for STMicro devices, or at least accelerometer-based devices?

I've attached photos of the two devices - the better photo is the new device. Are the lower numbers significant or just the S4?

I note a similar question in this thread:

https://community.st.com/s/question/0D53W00000BqHmmSAF/lsm6dso-and-lsm6dsox-sw-detection

jw56 · ‎2022-06-14

Wow, creepy - I just came here to ask this (but with LSM6DSO32 instead of X). The LSM6DSO32 even has different accelerometer ranges but still they gave it the same WHOAMI and I2C address... Not sure if there is a trick to tell these apart?

jw56 · ‎2022-06-15

@Community member So I think something you could do is try to write to 0x70. This register exists on the DSOX but no the DSO. It should start at 0x00, then write a non-zero value, read it back to verify, then set it back to zero. If it doesn't write, then you aren't using a DSOX so presumably it must be a DSO in your case.

Some of the other variants can be separated similarly, although I don't think this would work for every possible variant because there are some with exactly the same register mapping (DSO and DSO32 are an example) even though the values have different interpretations. In our case, to identify a DSO32 we will have to do some interpolation on our data server to decide which type of data we have and whether to apply x2 to the accel data.

I know that you likely aren't worried about our approach since they are different sensors, but putting it here in case someone else goes hunting for it 🙂

BWatsz · ‎2022-06-15

Thanks @jw56

LSM6dSOX has different registers. 0x70 is read-only (MLC Decision Tree result output), however that led me to think of other registers to check. LSM6DSOX has Embedded register 0x60 (EMB_FUNC_ODR_CFG_C) which is only used by the MLC (so not in LSM6DSO). It's value is 0x15 from power-up and can be change to 0x35 and 0x25 as per DS12814 so it seems to indicate it is the DSOX part.

It would be good to get confirmation from someone at ST.

My real problem (assuming it is an LSM6DSOX) with this device is that after the UCF file is loaded, the XL sample rate control register (0x10) won't save changes to the XL sample rate (the upper nibble) ...most of the time (yes I know that is a concern). So writing 0x10 is read back as 0x00, writing 0x28 is read back as 0x08, etc. So it's as though the UCF file load is preventing any changes to the XL sample rate. I'll need to step through the register changes in UCF to work out which part does this.

This all works on our original device and it's LSM6DSOX. Very perplexing.

The I2C signals look ok but some of the SCL timing looks tight (SCL high near 4us min width) so wondering about hardware layout on this new board. Although on the odd occasion when the XL sample rate register is set ok (or if it is set manually after power up and no UCF load), XL x,y,z values can be streamed ok from the XL.