Hello, I am currently trying to use the Sparkfun breakout board MPU6050 to measure angle. The code I am using is this:

#include "mbed.h"
#include "MPU6050.h"

DigitalOut myled(LED1);
Serial pc(USBTX, USBRX);
MPU6050 mpu;

int16_t ax, ay, az;
int16_t gx, gy, gz;

int main()
{
    pc.printf("MPU6050 test\n\n");
    pc.printf("MPU6050 initialize \n");

    mpu.initialize();
    pc.printf("MPU6050 testConnection \n");

    bool mpu6050TestResult = mpu.testConnection();
    if(mpu6050TestResult) {
        pc.printf("MPU6050 test passed \n");
    } else {
        pc.printf("MPU6050 test failed \n");
    }
   
    while(1) {
        wait(1);
        mpu.getMotion6(&ax, &ay, &az, &gx, &gy, &gz);
        //writing current accelerometer and gyro position 
        pc.printf("%d;%d;%d;%d;%d;%d\n",ax,ay,az,gx,gy,gz);
    }
}

This, and the Library were obtained from

http://mbed.org/users/garfieldsg/code/mpu6050_test/

I cannot make sense of the output I am getting in Tera Term, and the device always fails the test within the program

I have the device connected to p27 (scl) and p28 (sca)

Can anyone give me a hint into what I am doing wrong?

Thanks

Hi, have you fitted the pull up resistors to the I2C bus on pins p27 & p28?

I haven't, but I'm using a development board built specifically for the mbed which allows the mbed to be used in many ways, so all circuitry based problems should be addressed. I will try fitting some to a breadboard regardless and see if the readouts make more sense. I'll let you know how I get on. Thanks.

Can you post the output you are getting in Tera Term?

Okay, the pull up resistors made no difference to the output unfortunately

The output to Tera Term is as follows:

MPU6050 test
MPU6050 initialize
MPU6050::initialize start
MPU6050::initialize end
MPU6050 testConnection
MPU6050::testConnection start
DeviceId = 0
MPU6050 test failed
0;0;-7073;-29591;15630;-11988
0;0;2638;19987;-27830;-25830
0;0;2935;32297;26399;31290
0;0;8512;24265;15715;8331
0;0;-4756;15090;-6809;9224
0;0;-693;-6451;-8963;-25495
0;0;3269;-6258;-24871;1894
0;0;606;-9484;-1681;-24058
0;0;-30040;-10777;32764;23567
0;0;-6711;-8999;3921;5394
0;0;4220;-3883;6733;-4950
0;0;592;-155;-4287;-6656
0;0;-30357;32761;-12876;10316
0;0;-3614;-3194;7784;11370
0;0;-19396;-12930;-9762;-20120
0;0;-16183;16959;17305;26310
0;0;-17520;-10758;-29706;1555
0;0;30319;-32464;-244;-24112
0;0;552;31336;-6666;-16855
0;0;29123;-26002;12718;-7642
0;0;-26256;-6887;-26695;13285

I allowed for 20 cycles of the program and didn't physically moved the MPU6050 while doing so

I dont know the device, but since the testConnection is failing it is likely that you have a problem with the device slaveaddress. A quick check of the MPU6050.h shows that there are two possible slaveaddresses

#define MPU6050_ADDRESS_AD0_LOW     0x68 // address pin low (GND), default for InvenSense evaluation board
#define MPU6050_ADDRESS_AD0_HIGH    0x69 // address pin high (VCC)
#define MPU6050_DEFAULT_ADDRESS     MPU6050_ADDRESS_AD0_LOW

Which one should it be for your hardware?

Maybe try some low level checks first using the standard mbed I2C lib (just check for an acknowledge to the slaveaddress).

Are you sure that your MPU6050 is powered and that it shares a GND with mbed? Are you sure that you dont have SDA and SCL reversed. Note that the mbed I2C software will hang when you dont have the pull-ups installed. So that does not seem to be the problem.

My hardware is uding the default 0x68 (adress pin low) and all the wiring is correct.

I am in the process of going through the libraries and will let you know if I find anything.

Thanks

Okay, after having a look through the libraries I couldn't find anything obvious (not that I expected it), but I did notice some strange behaviour in Tera Term. When I reset the mbed the readouts I am getting are identical each time. I'm not to sure what that could mean, something writing to the wrong place perhaps? Any ideas?

There probably is no I2C communication with the sensor as long as you see "MPU6050 test failed". That will result in the libs failing or receiving values of 0xFF for all comms. The libs will somehow process that and give you identical meaningless results.

Have you tried basic I2C coms. Just send 1 byte to the slave and check the ack result. That has to succeed first before digging into the libs.

Its connection test fails, so you would expect it to give a constant output (most likely 0, although they arent initialized here, so any random value could be the case, as long as it is constant).

Normally because connection test fails I would say you really got a wiring error (either I2C, or power supply), or the address pin wrong. But that wouldnt explain the changing values. Although I really would make sure again you didnt mix up SDA and SCL.

Something not really that much related to his specific issue, but still relevant enough to mention: this library uses i2cdev files for i2c communication, so have easy commands for writing/reading stuff, that is handy to have. However this is the read command used in the library:

    char command[1];
    command[0] = regAddr;
    char *redData = (char*)malloc(length);
    i2c.write(devAddr<<1, command, 1, true);
    i2c.read(devAddr<<1, redData, length);
    for(int i =0; i < length; i++) {
        data[i] = redData[i];
    }
    return length;

I don't really see the use of first reading to redData, and then copying everything to data. However more important, and correct me if I am wrong since it isnt really my area, but isn't this a memory leak? In a function that will be called quite often. redData is everytime malloc'ed, but it isnt removed afterwards. And since it is just an internal variable no one else can remove it either. Won't be the issue now though.

Just to be sure, you can try the code from here: http://mbed.org/forum/electronics/topic/3097/?page=1#comment-19479. Then at least you can make sure the library isnt the issue.

Hi Erik,

Thanks for the library, appreciate it. I have been trying to get the simple test code you referenced above to work with my MPU module from sparkfun and my mbed FRDM25KLZ board. I keep getting a connection failed error. I have triple checked all the wires and made sure the port names are correct. I even tried another I2C Bus but got the same connection failed problem. The sparkfun breakouts do have the pull up resistors so that's out of the question.

If you could provide me with some pointers, that'd be great.

Thanks.

I assume you have this one: https://www.sparkfun.com/products/11028

Default is address pin low, so that should be fine unless you changed it. You connected ground to ground, Vdd to 3.3V, Vlogic to 3.3V and SCL and SDA to the correct pins on your KL25Z? Not the ASCL and ASDA pins?

Yes that's the one.

And correct, all those pins are wired correctly. I have wired the SCL and SDA and not the ASCL and ASDA pins. I havent changed the address jumper either.

I will try it on someones else's mbed at work tomorrow and see if it's a faulty board. It hasnt given me any problems thus far but this the first time I am using an I2C device with it.

I dug a bit deeper into your library and another one by Szymon Gaertig and realized that default address was set to 0x69 in your library.

#ifndef MPU6050_ADDRESS
    #define MPU6050_ADDRESS             0x69 // address pin low (GND), default for InvenSense evaluation board
#endif

After switching it to 0x68, connection was successful and I was able to get meaningful values from the device using an LPC1768 mbed - the exact same code just with different pin names doesn't work with my FRDMKL25Z. Quite strange.

Ah is that one wrong for address pin low.

I still have an MPU6050 here and also KL25Z these days, will have a look at it during the weekend. I know the KL25Z had an I2C bug, but should be fixed afaik.

Yeah I believe the default address is 0x68. It doesn't matter however because you are masking that bit (LSB) so in fact you are checking to see if the address is 0x68 anyways. I thought it would make a difference - but that isn't the problem.

That will be much appreciated. Yeah I have been reading up on the I2C problem as well. It seems they have fixed the problem quite recently so I updated my mbed library build but still no luck.

The address is relevant, since it is shifted one to the left by the library (7-bit address vs 8-bit address). So not the LSB is masked, but after shifting the LSB is masked.

Finally got to the bottom of it. Turns out the reference sheet that comes with the board has a mistake. I had been connecting SDA and SCL to the wrong pins after all. Frustrating but glad I got it to work. PTE0 and PTE1 are switched around on the reference card that comes with the board. See the following images:

Thanks for all your help!

Ah yeah, thats true. Well luckily you found it.