MMA8451Q Z-axis issues

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

MMA8451Q Z-axis issues

1,924 Views
kubiznak_petr
Contributor V

Hi everyone,

we are experiencing difficulties with the Z-axis of the MMA8451Q accelerometer. Running the (slightly modified) MQX's accelerometer demo on two devices, each accelerometer behaves differently and neither of them seems to work correctly.

 

Firstly the sensor is initialized with the following (unchanged) code:

/* Configure MMA8451Q */

  data[0] = 0x11;

    data[1] = 0xc0;

    mcI2C_write(I2C_ACCELEROMETER_BUS, I2C_ACCELEROMETER_ADDRESS, data, 2);

 

    data[0] = 0x2a;

    data[1] = 0x04 | 0x01;

    mcI2C_write(I2C_ACCELEROMETER_BUS, I2C_ACCELEROMETER_ADDRESS, data, 2);

It simply enables the orientation detection and activates the sensor. The rest is left untouched with the default values.

 

On the first device, the Z-axis does not seem to work at all, outputting always 0x8000. The orientation status does not change when flipping the device (see attached accel1.txt).

 

On the second device, the Z-axis output value also stagnates, but on a different value: 0xF5XX, i.e. the MSB part does not change, but the LSB part changes (see attached accel2.txt). But here, even though the value does not behave as expected, the orientation status changes correctly. And MSB sometimes (but rarely) also changes - just for one readout, even without the need to move the device (and the value change might be large, i.e. in tens). The attachment shows one such "flash", which was in this case caused by a short quick move (see the orientation status also changed). But as I say, these rare flashes appear randomly and are not conditioned by any movements performed.

 

Does anyone have an explanation for such behaviour? Might the first piece be connected to this announcement: http://www.freescale.com/files/shared/doc/pcn/PCN14989.htm ? And why the second gives unchanging values if it detects the orientation correctly?

Original Attachment has been moved to: accel1.txt.zip

Original Attachment has been moved to: accel2.txt.zip

Labels (1)
0 Kudos
5 Replies

1,125 Views
jiribartos
Contributor I

Hi everyone,

we have similar problem as P.K. with Z-axis of MMA8451Q, we soldered more than 3500 pcs of PCB and about 200 pcs don't pass a self-test and measuring in Z-axis has the same behaviour.

The behaviour of bad pcs:

1. Self-test

          X  = 90

          Y = 135

          Z = 0

2. Active state

          Z is always -8192

Please can you help us ?

Jiri

0 Kudos

1,125 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hi Petr,

First, sorry for not responding sooner, I have been out of the office the last couple of days.

It might be helpful to see your complete source code and not only the initialization of the device.

I would also recommend you to try a simple bare metal code (not MQX based) to better understand where the problem is.

The first device most likely has the stiction problem, but the second one behaves very strangely.

Regards,

Tomas

0 Kudos

1,125 Views
kubiznak_petr
Contributor V

Hi Tomas,

I tested your bare metal demo with the same result. I simply added printf to the cycle:

      printf("%04X %04X %04X\n", (unsigned short)Xout_14_bit, (unsigned short)Yout_14_bit, (unsigned short)Zout_14_bit);
      printf("%4d %4d %4d\n", Xout_14_bit, Yout_14_bit, Zout_14_bit);

That gives the following output for the first accelerometer (non-changing Z):

FFFA FFF5 E000
  -6  -11 -8192
0ED7 0035 E000
3799   53 -8192
024D F0F0 E000
 589 -3856 -8192
FFA9 0FB7 E000
 -87 4023 -8192
F026 02BB E000
-4058  699 -8192
FEF9 00DE E000
-263  222 -8192
FFFB FFF6 E000
  -5  -10 -8192
FFFA FFF6 E000
  -6  -10 -8192

... and the following output for the second accelerometer (perturbing Z):

FFAD 001B FFC3
 -83   27  -61
FFAD 001B FFC3
 -83   27  -61
FFAC 001B FFC3
 -84   27  -61
FFAC 001B FFC2
 -84   27  -62
002D 0EE4 FFC3
  45 3812  -61
FFE4 03A2 FFC3
 -28  930  -61
003E F084 FFC3
  62 -3964  -61
0EE3 00FB FFC3
3811  251  -61
EFDE 0175 FFC3
-4130  373  -61
FF54 FF7B FFC3
-172 -133  -61

Do you see any conclusions? Is this a hardware problem of the part? Then we would have to be really dissatisfied with its reliability...

0 Kudos

1,125 Views
TomasVaverka
NXP TechSupport
NXP TechSupport

Hi Petr,

Looking at the extracted data, the first device seems to be really bad due to stiction.

As for the second part, it does not look like hard stiction.

I have a few other questions to further investigate it.

Could you please send me a complete part marking found on the top side of both devices? 

Where did you purchase them from?

Do you have only those two samples or more parts? If more, have you already tested any of them?

Or are you using some of our development boards/kits with the MMA8451Q soldered onto a board?

As this issue requires more detailed communication I will also create a Service Request for you. You will receive an email from us acknowledging the creation of this Service Request. All additional communication should be primarily worked via this Service Request.


Regards,

Tomas

0 Kudos

1,125 Views
kubiznak_petr
Contributor V

Hi Tomas,

thank you for your reply. Please see attached source code - as I wrote, it is just a slightly modified official accelerometer demo primarily used for MCC demonstration.

I will try your bare metal demo as soon as possible, then I will let you know.

0 Kudos