MMA9553L - INT_O_FRAME_EN not working

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

MMA9553L - INT_O_FRAME_EN not working

1,133 Views
piotrjuda
Contributor I

Hello.

I am working with MMA9553L. So far I was able to successfully configure various applications (e.g. AFE and pedometer) and read data from them. I am currently trying to configure the system to use the frame-based interrupt on pin INT_O but it is not working. I was able to configure the interrupt to be asserted after a mailbox command has been processed by sending 0b10000000 as a configuration byte to the MBOX configuration app, but sending 0b10100000 or 0b00100000 results in the INT_O pin staying low all the time. What should I do to enable the interrupt?

Labels (1)
0 Kudos
3 Replies

826 Views
maureen
NXP Employee
NXP Employee

Hi Piotr,

If you read the AFE/frontend application twice, does the accelerometer data change? It's possible you might need to wake the part up out of deep sleep mode. Another hint would be to look at the current consumption - in deep sleep mode it is about 2 uA. In this mode, the AFE is not clocked so you will not see any frame interrupts, but you can still send slave port commands. See MMA9553LSWRM section 2.6.12:

2.6.12 Wake up from Deep Sleep (Stop No Clock mode)

By default, the MMA955xL initializes all applications after a hardware reset and then falls into Deep Sleep mode where all system clocks are stopped. A slave-port command can be used to wake up the clocks, enable the accelerometer, and execute the pedometer.


This command writes one byte of configuration variable to the sleep/wake application (APP_ID=0x12) starting at byte offset 6.

12 20 06 01 00

(these are all hex)

0 Kudos

826 Views
piotrjuda
Contributor I

I am disabling the sleep mode right after start-up by sending the same command already. The values I am reading from the accelerometer (all AFE values) change from sample to sample and they appear to be 100% correct. I have checked another chip and it behaves in the same way.

To elaborate, maybe you can spot an error in my code:

My mailbox configuration application (0x18) configuration register's value (let's call it config) is made by ORing the following:

typedef enum {

    acc_Mailbox_Config_INT_O_EN                                    = 0b10000000,

    acc_Mailbox_Config_INT_O_POL                                = 0b01000000,

    acc_Mailbox_Config_INT_O_FRAME_EN                            = 0b00100000,

    acc_Mailbox_Config_INT_O_Legacy_Mode                        = 0b00010000,

    acc_Mailbox_Config_INT_UpdMode_Always                        = 0b00000000,

    acc_Mailbox_Config_INT_UpdMode_Port_Inactive                = 0b00000100,

    acc_Mailbox_Config_INT_UpdMode_Port_Inactive_With_Interrupt    = 0b00001100,

} acc_Mailbox_Config_t;

when config == 0, config == acc_Mailbox_Config_INT_O_FRAME_EN or config == acc_Mailbox_Config_INT_O_EN | acc_Mailbox_Config_INT_O_FRAME_EN no interrupts are asserted,

when config == acc_Mailbox_Config_INT_O_EN the interrupt is asserted every mailbox request (as expected).

0 Kudos

826 Views
JackITB
NXP Employee
NXP Employee

Hi Piotr,

If you set MBOX Config to 0xB0 (EN | FRAME_EN | LEGACY), the INT_O behaves as a data ready flag (is asserted when new samples are available). Then INT_O line is deasserted when any slave transaction occurs so read what you need first off.

For example, you can directly fetch the XYZ stage0 data in MB26 to MB31 (default assignement of the Quick-Read mailboxes in legacy mode). You can also customize the content of MBoxes 04 to 31 with APP_ID 0x04 (see table 7.1 in MMA955xL_SWRM).

This scheme (Frame_En + Legacy) mimics the operation of standard sensors with a data ready INT, and avoids the 2 steps transaction: send a command/query then read the answer

0 Kudos