cancel
Showing results for 
Search instead for 
Did you mean: 

LIS2DE12 mangles REG1 register

thingamabyte
Associate

I'm attempting to use the LIS2DE12 in perhaps the simplest configuration: To directly poll the X,Y,Z registers as needed. I'm using the I2C bus. At this point, I've added some debug checks, so the current process looks like this:

 

1. On wakeup, I read the WHO_AM_I register to verify I'm talking to the correct device. I am.

2. (debug) I read all the read/writeable registers so I can see what they are. All of them match the documentation's default values except CTRL_REG1 (0x20). Instead of the expected response of 0x07, I get 0x01. 

3. I write to CTRL_REG1 (0x20) the value 0x5F. According to the docs, this should enable X, Y, Z, enable the device, and set the rate to 100Hz

4. (debug) I read all the readable values. All other writeable registers are still defaults, but the CTRL_REG1 register has changed... but it doesn't contain 0x5F... it contains 0x02 !? Also interesting is the X, Y, and Z all contain non-zero values at this point, but the STATUS register reads 0x00 (no data, no overruns). On a few runs, there was data at this point, but it quickly was cleared on following reads.

5. I read the STATUS register, and if the lower 3 bits are set, I read the appropriate X, Y, Z values. The status register never returns 0x00 at this point.

 

Anyone have ideas of what could be happening here? 

 

1 ACCEPTED SOLUTION

Accepted Solutions
thingamabyte
Associate

We used your examples as a reference when building the code in the first place. 

We ended up figuring out the problem. The platform we're using had a bug in its I2C implementation. It would sometimes clock out an additional byte after messages. It appears this part replies by overwriting the specified register with the additional byte's (random) contents.

Fixing this bug fixed the problem.

View solution in original post

2 REPLIES 2
Federica Bossi
ST Employee

Hi @thingamabyte ,

Have you already looked at our PID examples on Github?

I think they could be useful to understand if it is a problem with your code or if it is the sensor.

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.
thingamabyte
Associate

We used your examples as a reference when building the code in the first place. 

We ended up figuring out the problem. The platform we're using had a bug in its I2C implementation. It would sometimes clock out an additional byte after messages. It appears this part replies by overwriting the specified register with the additional byte's (random) contents.

Fixing this bug fixed the problem.