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.
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...
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.
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.