MMA9555L INT_O configuration

[neilporven]

Hi everyone,

I am having trouble understanding how to configure the INT_O.  Two things are happening that could be

the reason why I believe it is not working.

1. If I free run the software, I loose Arbitration in my I2C routine. This does not occur if I step through the commands.

2. If I place my scope with a trigger on IO5, I don't see the transition from low to high or triggered.

This is my setup or sequence of configuration for the MMA9555L:

Send Wake Up command

Send INT_O command

Send Read 6axis register command

then I wait to see if INT_O gets set by the MMA9555L

Do I need to configure/send additional commands prior to sending these commands?

Why do I loose arbitration when I let the program run?

I am using a freedom Kinetis K46L eval board by the way.

Thanks,

Neil

[neilporven]

Quick update,

I noticed that on the previous response, the starting calling address was W4Ch it should have been R4Ch.  So I changed it and now I am getting

this is the ending:

I believe the response should be 12h 80h 01h 01h

Please let me know if this is making more sense?

Thanks.

[neilporven]

Hi Jacques,

I switched the data description to HEX this is why the first capture was not making sense.

I am going to have to split it because I can display all of it at once.

First Half of the Wake-Up command

Second Half of the Wake-Up command

Final Half of the Wake-Up command

The Wake-Up command is followed by the sanity check of it by reading it back.

First Half of the Read of the Wake commad

Second Half of the Read of the Wake command

The response is still the same as above.  It seems that the unit is ACKing properly with each byte sent, but according to the result displayed,

the MMA9555L is replying with FF for all fields.

Can you spot what could be happening?

[neilporven]

Hi Jacques,

Here is a better capture

Not sure what this is?

Response

Not sure if you can make any sense of this?

Thanks,

Neil

[neilporven]

Sorry Jacques,

I just got this logic analyser and I am learning how to set it up and capture my communication.

Here is a capture of the wake-up portion.   HEX  98(address TX), 12(AP ID), 20(write command), 06(offset), 01(bytes to write), and 00(wake-dude!)

I will do the same tomorrow for the other commands, please let me know what you think so far?

Thank you,

Neil 

[JackITB]

Hi Neil,

Hard to say from the picture, besides the fact that SDA and SCL on the table are swapped compared to their plots (Red is SCL).

I recommend also that you perform a "read response" after each command (+ a few ms delay) to make sure it has completed without error. Second byte shall be 0x80, as per datasheet §4.3.3 page 23:

[neilporven]

A quick update,

I believe issue 1 (arbitration) is taken care of.  I also found that I was sending

INT_O

Write: 18 20 00 01 80  instead of 18 20 01 80

after correcting these two things I am still not getting an interrupt?

can someone help?

[JackITB]

Hello Neil,

After a quick test on KITMMA9555LEVM demokit, I've no issue to program the INT_O sensor pin as "Command completed" Interrupt line.

Here is the communication between host MCU and MMA9555L as well as INT_O signal.

WRITE TRANSACTION :: Starting MB = 00
Write : 12 20 06 01 00 // disable sleep mode (STOPNC) in Sleep-Wake Application

   

WRITE TRANSACTION :: Starting MB = 00
Write : 18 20 00 01 80 // enable INT_O (to flag command completed) in Mailbox Application

Once this command is completed (takes about 185µs), INT_O is asserted and will stay so till next transaction on MMA9555 slave interface 

WRITE TRANSACTION :: Starting MB = 00
Write : 1A 30 00 01 // query SixDir Status register in 6-axis Application

This command immediately clears INT_O line. Then after command is completed and results made available in the mailboxes, INT_O is asserted (goes high) so the host MCU knows data is ready and can be read
READ TRANSACTION :: Starting MB = 00, No. bytes to read = 5
Read : 1A 80 01 01 06 // board sits horizontal on the table => orientation = +Z

This clears the INT_O line again.

Please provide communication log so we can check the traffic between your MCU and sensor.

Regards,   Jacques.