PiBurgh
Posts: 5
Joined: Wed Feb 27, 2013 3:18 am

Help with MMA8452Q over I²C

Wed Feb 27, 2013 4:14 am

Anybody had any luck communicating with the MMA8452Q accelerometer (Freescale) over I²C?

This is a cool chip with lots of on-board features (pulse sensing, etc.) that I'd like to use to save processing time on the RPi and I'm using the BoB from Sparkfun, but having trouble with communications.

Symptoms:
Hooked up to RPi rev. 2 on the i2c-1 lines, powered by 3.3V. i2cdetect -y 1 shows the device is indeed there and at address 0x1D. That's about as far as I get. An i2cget of the chip ID register returns 0x00. In fact, an i2c dump of the entire register set returns all zeros. It's like the data lines aren't registering. Simple voltage reading at idle shows both lines being pulled up high to 3.3V - looks like it's all a go. I don't have anything as sophisticated as an i2c monitor.

Based on web forums, I've tried three different things that have all failed...

Baud Rate
The chip is supposed to handle 100kHz; 400kHz in Fast mode. I've tried to slow it down. Some people have had better luck at 32kHz and even all the way down to 800Hz. I've tried a number of speeds in between and can't find a sweet spot. I'm thinking that's not it.

Drop Voltage on BoB
Found a long thread of Arduino users who were having similar issues. Seems that at 3.3V power, the lines weren't dropping all the way to (0.3 x Vddi/o) and the UART was seeing the lines as always high; no signal. One guy ran the chip at 5V and claimed that it worked, even though Freescale warns against powering with anything over 3.7V or damaging the chip. Using just the power line (SDA and SCL unconnected) I risked hitting the chip briefly with 5V. No smoke. However, the SDA and SCL lines both pulled up to around 4.8V, which would probably do damage to the RPi if I hadn't had the forethought to unconnect them first. This was an odd thread with lots of conflicting info and unclear if they were using the Sparkfun BoB or one of their own creation. Without any way to confirm the low signal level without an analyzer, I moved on.

I²C Protocol Caveat
There was one thread of very excited guys that figured out that the wire.c library they were using was not sending the repeated starts on from the master on the i2c reads. One of 'em modified the wire.c library to use the proper protocol and they were all jumpin' fer joy. Unfortunately, I see many users here have used the ADXL345 with no difficulty and the documentation for that chip shows exactly the same protocol required by the MMA8452Q.

Moving Forward
So I've ordered a couple of ADXL345 chips. We'll see if I have better luck with those.
However, I'd still like to get the MMA8452Q working as it has some really nice sensing features that I'd like to make use of. I haven't tried accessing the chip from python (smbus) or C++ (wire), but I may try those next. I just figured if the command line access using i2ctools didn't work, nothing would. I'll keep you posted on that front. If anyone has any ideas, I'd appreciate hearing from you.

Thanks in advance.
Jeff

PiBurgh
Posts: 5
Joined: Wed Feb 27, 2013 3:18 am

Re: Help with MMA8452Q over I²C

Thu Feb 28, 2013 4:22 am

Trying to access the chip through a Python script using the smbus import didn't work either. Registers returning zeros.

Bother... :?:

PiBurgh
Posts: 5
Joined: Wed Feb 27, 2013 3:18 am

Re: Help with MMA8452Q over I²C

Fri Mar 01, 2013 12:30 am

Update
Tried a second MMA8452Q and even swapped out the RPi Hardware just in case the accel or the GPIO hardware was DOA.....no luck - same results. Also tried accessing the unit through a Python script using the smbus library....no luck - same results.

There are 10k pull-up resisters on my Breakout board. Could this be interfering with pull-up behavior that is already happening on the GPIO?

frisbone
Posts: 21
Joined: Sun Mar 10, 2013 9:41 pm

Re: Help with MMA8452Q over I²C

Wed Mar 13, 2013 12:15 pm

Did you have success with this? I am doing this very soon myself with the same board with a Rev2 RPi. Would love to learn from your mistakes ;)

Could you post some pics of your connectivity and links to software setup, etc? If you are still having issues perhaps we could collaborate.

Ian

webdude22
Posts: 6
Joined: Tue Mar 12, 2013 2:28 am

Re: Help with MMA8452Q over I²C

Wed Mar 13, 2013 9:46 pm

I am also trying to get this sensor to work using the Pi4J (Java) libraries on a Rev 1 RPi. Currently I have the same outcome as you... i2cdetect discovers the device but anytime I try to perform a read it returns 0.

I know that I have everything wired correctly and that my RPi's i2c is working because I am able to communicate with a temperature sensor on the same bus.

Have you made any progress since your previous posts?

PiBurgh
Posts: 5
Joined: Wed Feb 27, 2013 3:18 am

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 2:22 am

OK, here's an update. Since the I2C on the GPIO has its own pull-up resistors, I did two things:

1) ripped the pull-up resistors off the sparkfun BoB (unsoldered R1 & R2) - same behavior.

2) I implemented i2c-0 on P5 on the RPi which has no pull-ups and use my other MMA8452Q that still had its pull-ups intact. - same behavior.

In mad frustration I simultaneously placed an order for an ADXL345. In seconds of its arrival I had it wired up on the breadboard and it instantly (well, once I figured out CS had to be pulled high and SA0 pulled low) started communicating with the RPi. After I verified this with i2cdetect and i2cdump (which now returns non-zero values from the appropriate registers), I got a Python program running that plots the X, Y, Z values in real time. No sweat. I can post my Python script, but that wasn't the issue.

Still don't know what's wrong with the MMA8452Q. Don't think I'll be able to sort it out without an oscilloscope or i2c monitor that can watch the SDA line to see what's happening there.

Ideas welcome...

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 10:01 am

I had a quick look at the device datasheet and could see no reason for the failure, and as I dont have one or the spare time at the moment I could not run it up on the scope and other tools.

It appears to be a poorly I2C compliant device, I have come across a few over the years.

I could be wrong and it is something, else but without a unit I could not tell
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

frisbone
Posts: 21
Joined: Sun Mar 10, 2013 9:41 pm

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 7:29 pm

Same issue as everyone else - WHO AM I register returns 0
Out of curiosity - did anyone notice that the example program (arduino) shows a data rate set of 115200?

I'm using the wiringPi library and it has a data rate set capability:

gpio load spi [rate] - but its in Kbps. I do wonder if we have to be matching a built-in data rate.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 7:42 pm

But its an I2C device not SPI. The data rate is set elsewhere and the device claims 400kHz compatability.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

frisbone
Posts: 21
Joined: Sun Mar 10, 2013 9:41 pm

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 7:51 pm

Yeah, I noticed that mistake (I think anyway) - following advice from the following link:

https://projects.drogon.net/raspberry-p ... c-library/

Guess it was just a typo - but still doesn't have an effect when you correct it to i2c. I've seen another example program for Arduino now with a data rate of 9600. So red herring I suppose.

When you say it is set elsewhere - where exactly are you refering to? I'm using the C lib - are you using Python?

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 7:59 pm

I2C clock rate has a default setting done at system startup. Default is 100kHz
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 8:00 pm

If I had the device and some time I would run it up, but both are lacking at the moment.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

frisbone
Posts: 21
Joined: Sun Mar 10, 2013 9:41 pm

Re: Help with MMA8452Q over I²C

Thu Mar 14, 2013 11:21 pm

Look at this last post on the SparkFun site by Joeisi :

https://forum.sparkfun.com/viewtopic.php?f=32&t=31340

Not sure if that applies to RPi users using the 3.3V off of the RPi. But then again I'm not smart enough to determine if the RPi schematic creates a similar similar situation necessitating a Logic Level Converter. Anyone smarter have any thoughts?

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 1:26 am

No thats about the other way round. MMA8452Q is 3V3 and interfacing with a 5V Mega or simliar needs level translater.

This is a 3V3 device talking to a 3V3 i2C master so does NOT need a level translater.

What it needs is one on a Pi and being scoped with known command sequences to see what happens.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

webdude22
Posts: 6
Joined: Tue Mar 12, 2013 2:28 am

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 2:59 am

So I finally had some time today to do some troubleshooting and captured some oscilloscope readings. I had only the MMA8452Q connected to the I2C pin at address 0x1D and I ran a program that tried continuous reads from the WHOAMI byte at 0x0d. The results are available at: http://dl.dropbox.com/u/2468008/I2C_debug.pdf

I used the following link to interpret the capture:
http://www.best-microcontroller-project ... orial.html

From the capture, it looks to me like everything is functioning as expected except that the MMA8452Q is returning 0x00 as data. I'm still not sure why this is not working.

Also, Let me know if you would prefer the raw data as a CSV file or would like a different capture.

webdude22
Posts: 6
Joined: Tue Mar 12, 2013 2:28 am

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 3:22 am

I was just looking through the capture again and the spec for the MMA8452Q (http://dlnmh9ip6v2uc.cloudfront.net/dat ... A8452Q.pdf page 17) and noticed that the RPi might not be sending a repeated start.

There seems to be a post about this here http://www.raspberrypi.org/phpBB3/viewt ... 44&t=15840

webdude22
Posts: 6
Joined: Tue Mar 12, 2013 2:28 am

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 4:00 am

Last update for today, I tried performing a block read (multiple bytes) using the Pi4J library and I did seem to get data (not zeros)... although it was not values I was expecting. I'll try to look into this more tomorrow.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 8:55 am

Hmm, the trace looks a bit glitchy, whats worrying me is your trace is showing SDA changing on the falling edge of SCL, which should be just after when SCL is LOW otherwise the changes in SDA can be interpreted as STOP of START conditions.

These however may artifacts or aliaising due to scope bandwidth and sampling setup.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

webdude22
Posts: 6
Joined: Tue Mar 12, 2013 2:28 am

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 12:55 pm

This might be due to the scope I was using. Its a college supplied USB signal capture board (http://mobilestudio.rpi.edu/) that probably isn't quite as accurate as a dedicated oscilloscope.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 1:08 pm

Probably is, where abouts are you?
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

webdude22
Posts: 6
Joined: Tue Mar 12, 2013 2:28 am

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 2:05 pm

Here is the output I am getting for a print out of the first 14 elements (should be addresses 0 to 0xd):
Element 0-0
Element 1-6f
Element 2-e4
Element 3-39
Element 4-7c
Element 5-68
Element 6-4
Element 7-0
Element 8-6f
Element 9-e4
Element 10-39
Element 11-7c
Element 12-68
Element 13-4


Here is what I think is going on: When a normal write operation is performed, the RPi sends a write command updating the register on the MMA8452Q with the address to start reading from. This command is then ended with a stop command which clears this register back to 0x00 on the MMA8452Q. Then a read command is sent out and the RPi gets the value stored at address 0x00. If a block read is performed, the RPI sends out a read request and does not send out a stop command (which should also be a repeated start) until 7 bytes are read. This allows the MMA8452Q to send back values for the first 7 registers as shown by my output. This means that performing a block read seems to be a work around but only for reading the first 7 bytes. It seems that the MMA8452Q really needs a repeated start to be sent out to perform any single byte reads (except reads to 0x00) or block reads past 0x06.

I'm not sure why I can only read the first 7 bytes before a stop command is sent out...but it might be part of the I2C protocol

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 2:18 pm

webdude22 wrote:Here is the output I am getting for a print out of the first 14 elements (should be addresses 0 to 0xd):
Element 0-0
Element 1-6f
Element 2-e4
Element 3-39
Element 4-7c
Element 5-68
Element 6-4
Element 7-0
Element 8-6f
Element 9-e4
Element 10-39
Element 11-7c
Element 12-68
Element 13-4
Second half is repeat for first half
Here is what I think is going on: When a normal write operation is performed, the RPi sends a write command updating the register on the MMA8452Q with the address to start reading from. This command is then ended with a stop command which clears this register back to 0x00 on the MMA8452Q. Then a read command is sent out and the RPi gets the value stored at address 0x00. If a block read is performed, the RPI sends out a read request and does not send out a stop command (which should also be a repeated start) until 7 bytes are read. This allows the MMA8452Q to send back values for the first 7 registers as shown by my output. This means that performing a block read seems to be a work around but only for reading the first 7 bytes. It seems that the MMA8452Q really needs a repeated start to be sent out to perform any single byte reads (except reads to 0x00) or block reads past 0x06.

I'm not sure why I can only read the first 7 bytes before a stop command is sent out...but it might be part of the I2C protocol
The 7 bytes limit will be because one of the following (not necessarily your case) -
  • Master stops at 7 due to some software reason
  • Early reading stop due to NACK on bus
  • Fault on bus
  • Fault in device
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

photomankc
Posts: 80
Joined: Fri Aug 24, 2012 12:58 pm

Re: Help with MMA8452Q over I²C

Fri Mar 15, 2013 3:46 pm

So lack of a repeated-start condition strikes again. This is something I have bumped up against a few times. If you ever interface to a PICAXE 18M2 or higher as an I2C slave you'll hit the same issue there as well. The auto increment feature on the PICAXE resets to zero when the STOP command hits and you end up always starting your READ from 0x00 no matter what address you requested in the previous WRITE.

I have written custom code for another micro to do I2C with repeated start because keeping the transactions short was essential but on the Raspberry I think you are just hosed because the Broadcom I2C implementation does not do repeated start. You just have to read the whole chip and extract the part you want.

PiBurgh
Posts: 5
Joined: Wed Feb 27, 2013 3:18 am

Re: Help with MMA8452Q over I²C

Sat Mar 16, 2013 12:50 pm

WOW! Thanks everybody. I think you've hit on it. Knowing this issues with the BCM2835 it's easier to search and see that LOTS of other people have hit on it as well: The RPi won't send repeated starts!

Some chips handle a STOP|START as a repeated start, while others, holding to be more I2C compliant, do not. Looking at the I2C spec, it looks like the reason for a repeated start is to maintain control of the bus, which is why some chips like the MMA845xQ are more "picky" about requiring it. The STOP|START that the RPi sends out allows a brief moment when the I2C bus can be grabbed by another chip and the intended multiple write/read operation can get interrupted. This looks like a relaxed standard that the BCM2835 or its drivers have implemented, which is acceptable if you only have one master on the bus and take care not to talk to more than one (non-picky) slave on the bus at a time.

I'm glad at this point that I only spent $10 each on my MMA8452Q chips! My "non-picky" ADXL345 will have to do for this project.

techpaul
Posts: 1512
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
Contact: Website

Re: Help with MMA8452Q over I²C

Sat Mar 16, 2013 2:32 pm

Quite often the 'picky' devices reset things internally on a STOP condition and must have a START condition to do things like read registers.

Majority of devices tend to reset only the I2C communication not any internal actions on STOP conditions, so can be driven with repeated start or stop and start.

Unfortunately this sort of criteria is down to the device and I2C does not mandated controllers must be able to do repeated start conditions (most can or their driver supports it)
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/

Return to “Automation, sensing and robotics”