Hi all,

I've been trying to get the MPU6050 libsworking,and I've been having a lot of trouble. To start with, I simply imported this (http://mbed.org/users/garfieldsg/code/MPU6050/) library and tweaked it as required to work with the STM32. All that was really required were pin changes. My new program is here: http://mbed.org/users/chris1seto/code/mpu6050_test_basic_1/

Although the connection test passed, the getmotion6() call is returning all zeros no matter what. What's even more interesting is that even down to the i2c transaction in i2cdevlib's files, the call to i2c.read(devAddr<<1, redData, length); is returning all zeros.

I am sure that the MPU is wired correctly. It works just fine on the Arduino version of the libs. It does pass the i2c connection test and I used a scope to verify that some kind of data exchange was taking place.

Any ideas?

One method to get alot of zeros from the device (from experience), is when it isn't moved into active mode, but it seems it is doing that. What if you use one of the other libraries? For example: http://mbed.org/users/Sissors/code/MPU6050/ (You might need to modify the address in the .h file, it is a very old lib from me, might update it some day to be a bit more polished, but it should work).

Got that library working this morning! See: http://mbed.org/users/chris1seto/code/MPU6050_noni2cdev/

I guess I need to go through and try to determine why the i2cDevLib isn't working, though

VERY interesting development....

Line 137/138 in I2Cdev.cpp

    i2c.write(devAddr<<1, command, 1, true);
    i2c.read(devAddr<<1, redData, length);

^{That fails!!}

This, however, works.

    i2c.write(devAddr*2, command, 1, true);
    i2c.read(devAddr*2, redData, length);

...What?! Almost looks like there could be a data hazard the compiler is causing.

IIRC I believe there was someone else with problems with this MPU6050 lib with a Nucleo device (although I believe it didn't compile at all, so it must be something different). That was related I think due to all Nucleo targets for some reason using uARM instead of ARM (not that it should matter for something like this lib). But I wouldn't know exactly what it was anymore.

That certainly should be the same, since devAddr is just an uint8_t. It might give slightly different timings, thats all I can think of.

Hi Erik,

I know of that issue. It was actually caused by the inclusion of iostream, which is not necessary anyway. I removed it and have been able to get the DMP libs compiled no problem.

Hi Chris,

My target is Nucleo F401RE, tried to import the library from http://mbed.org/users/garfieldsg/code/MPU6050/, changed I2C pin name, compiled no problem but the testConnection fail all the time. Could you please help on this?

Thanks Phuong

Hey Guys, I just published forks of modified libraries and example codes for usage of MPU DMP on Nucleo. Check it out here:

It seems that Nucleo likes only a particular way of I2C start and stop signals. Also, I can confirm that the following 8-bit I2C device address define method works on Nucleo.

i2c.write(devAddr<<1, command, 1, true); 

I know this is an old thread, but I guess it is the only discussion that pops up when you search for MPU on ST Nucleo; might help a few...

PS: I am using ST-Nucleo F411, will test with other boards when I get a chance...

Cheers!

Akash

You saved me a lot of time, thanks!

How did you calibrate your offsets? I am trying to check this out for almost one week but I cant get a satisfying solution.

I tried this code too: http://www.i2cdevlib.com/forums/topic/96-arduino-sketch-to-automatically-calculate-mpu6050-offsets/ But it doesnt work as expected.

You are welcome! I am about to write an automatic calibration routine to determine the offsets, if I get time I'll post one this week. Until then you could just try looking at the raw Gyro & Accelero outputs and adjust the offset manually...

I tried it manually and I can read the raw Gyro & Accelero raw outputs and the offsets.

Right now my problem seems to be that I can't do any changes by setting different values in the structure "Offset".

I don't know where the failure might be, maybe you can help me again.

Edit: The problem was that I couldn't write into the register with the "writeWord." function from I2Cdev.cpp . It has to be "WriteBits".

Nevertheless I have some questions about the registers.

Why did you chose your offset registers to be the "SELF_TEST_X_GYRO" (0x00) register? And for the acceleration you have chosed for example the "XA_OFFSET_H" (0x06).

The "SELF_TEST_X_GYRO" (0x00) worked fine for me, but to change the value of the acceleration offset I had to write into the XA_OFFSET_L (0x07) register.

Maybe you have some answers for me ;)

Bye

Have you ever tried with Nucleo F103? Thanks

I can run your codes on F103 now but "FIFO overflow" occurs very frequently. What's the problem?

I dont have a F103, the code works well on F401 and F411, not sure why you are getting this error. Are you using the exact same sample code [MPU9150_nucleo_i2cdev]? The non I2C dev version has FIFO overflow problems...