MMA8452Q - Strange values upon power up/chip reset

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MMA8452Q - Strange values upon power up/chip reset

Jump to solution
873 Views
anon-ef9907ee3c
Contributor I

Hello everybody,

We're currently integrating a test routine for a MMA8452Q accelerometer. This routine is run each time our device is plugged (i.e. power supply comes up to the device and hence, to the chip).

To test this, we simply read the static acceleration, and compute the global acceleration that is expected to be close to 1 g as sqrt(x²+y²+z²) (gravity only, the device is not expected to move right after being plugged). No motion occured wile doing the tests.

The test goes as follow:

1) Device is plugged (power supply ON)

2) reset the accelerometer using the I2C command

3) disable the accelerometer using the I2C command

4) configures it for reading static acceleration only

5) enables it back the accelerometer using the I2C command

6) read 3 axis acceleration (once)

7) computes global acceleration and compares it to 1 g

8) disable accelerometer for power saving

9) device is unplugged (power supply off)

The fact is that upon certain conditions the acceleration is not within the range, but around 2 g...

Here are some experiments that have been done (results are repeatable):

- insert delay between steps 4) and 5) => acceleration Ok (around 1g)

- run to step 7) included, remove step 8) and reset the program to step 2) without unplugging the device (power supply is maintained) => acceleration Ok (around 1g)

My analysis: it seems the first accelerometer data upon chip power on (not on reset) are not valid, or take sometime before being valid (due to configuration change ?).  Adding some delay between applying new configuration and reading first value seems to solve the problem, but I do not understand why this happen.

Does anybody have already encountered such a problem and would have an explanation ? I would like to be certain adding a delay will always solve this problem...

Thank you very much for your help.

Best regards,

Simon

Labels (1)
0 Kudos
1 Solution
646 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Simon,

You need to take into consideration the Turn-on time (see Table 3 of the data sheet) and also wait some time until new data is available by checking the ZYXDR bit in the Status register 0x00.

After issuing a software reset by setting the RST bit in the CTRL_REG2 register 0x2B, it is also recommended to wait until the RST bit is hardware cleared.

Regards,

Tomas


PS: If my answer helps to solve your question, please mark it as "Correct" or “Helpful”. Thank you.

View solution in original post

0 Kudos
3 Replies
647 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hello Simon,

You need to take into consideration the Turn-on time (see Table 3 of the data sheet) and also wait some time until new data is available by checking the ZYXDR bit in the Status register 0x00.

After issuing a software reset by setting the RST bit in the CTRL_REG2 register 0x2B, it is also recommended to wait until the RST bit is hardware cleared.

Regards,

Tomas


PS: If my answer helps to solve your question, please mark it as "Correct" or “Helpful”. Thank you.

0 Kudos
647 Views
anon-ef9907ee3c
Contributor I

Hi Tomas,

Just finished to test your proposals.

It appears that waiting for the data available bit between each measure solves the problem.

I also added by safety a turn on time delay after each transition from standby to power on.

I did not try to wait the reset bit, up to now the first solution seems to be efficient. Moreover there's something ambiguous in the datasheet, CTRL_REG2 RST bit description: "Reading this bit will return a value of zero.". So I was not sure how to wait until the but gets cleared if reading it returns 0....

Anyway, that solved my problem, thank you again.

Best regards,

Simon

0 Kudos
647 Views
anon-ef9907ee3c
Contributor I

Hello Tomas,

Thank you for your help.

That's indeed something we did not take into account at all.

I'll perform some tests today to check the 3 points you detailed, before marking the thread as solved

Thank you very much and have a nice day.

Simon

0 Kudos