MPU6050 with DMP active hangs indefinitely using Arduino Wire library #252

batata004 · 2016-06-24T03:48:36Z

Sometimes my Arduino freezes or crashes when using JEFF ROWBERG library to read DMP data from MPU6050. It took me almost a full year to discover the problem and today I had some spare time and I tried to find where exactly arduino hangs/freezes.

I discovered it is usually when executin getFIFOCount() or getIntStatus(). I discovered that inserting many Serial.print with tags along my entire code so I could know exactly which line hanged. So I discovered everytime my arduino hanged/freezes it was at a line with getFIFOCount() or getIntStatus(). So I decided to take a close look at it.

Inside the file MPU6050.cpp there is a code like this:

uint16_t MPU6050::getFIFOCount() {
I2Cdev::readBytes(devAddr, MPU6050_RA_FIFO_COUNTH, 2, buffer);
return (((uint16_t)buffer[0]) << 8) | buffer[1];
}

I checked the function "readBytes()" inside I2Cdev.cpp and I found this:

I2Cdev::readBytes(uint8_t devAddr, uint8_t regAddr, uint8_t length, uint8_t *data, uint16_t timeout)

You see the problem? The function readBytes accepts one last parameter which is "timeout" but the function getFIFOCount uses readBytes without the timeout parameter! That's probably a bug cause sometimes I think the readBytes takes too long to execute and a TIMEOUT SHOULD BE set to avoid the function hanging out forever.

I am pretty sure maaaany MAAAANY other people alterady experienced this problem and spent a lot of time trying to understand what went wrong. Some people mistakenly believe it's related to bufffer overflow in the FIFO or because of some non optimized code. It could be the problem but MY PROBLEM FOR ALMOST A FULL YEAR has been this bug reported here.

I really hope someone fix this and add a timeout so nobody would spent entire months anymore seeking a problem that's is really hard to track an intermitent.

bishwa9 · 2016-06-27T23:43:53Z

This is my first time using the library and I think I am running into this issue as well. Did you figure out what timeout to give?

Thank You.

batata004 · 2016-06-28T15:02:51Z

No, it looks like this library support is dead. I think we should move to other alternatives cause this library has already many bugs documented and unresolved so it's really unreliable if you are gonna use this library to anything serious. Jeff Rowberg is not providing the good support he gave to this library in the old days so I think you would be better off this library

jrowberg · 2016-06-28T15:37:58Z

Apologies for the lack of support. I've tried to migrate most of the effort to online forums and other willing (and often more capable) contributors as much as possible, since I can't devote the time to this that I used to. The best laid plans of mice and men, as it were...

However, in this case, I strongly doubt that it is the lack of a timeout argument that is causing the underlying issue. Arduino's Wire library does not actually provide timeout functionality. If you dig into the code, you'll see a blocking loop in the TWI calls. See this for example:

arduino/Arduino#1476

Supplying a timeout in I2Cdevlib code would make zero difference, because there's no way to pass it to the underlying Wire/TWI implementation. The only way around this is to use a different timeout-capable I2C implementation. This is possible, but not simple.

I would recommend checking the SDA/SCL lines with a logic analyzer to see when/why the sensor stops responding. The blocking loop inside Arduino's Wire/TWI code should not hang as long as the sensor responds according to the I2C spec.

batata004 · 2016-06-28T16:21:40Z

@jrowberg I never wanted to offend you. I know you did this library for free and you are contributing a lot with the community providing it to general use. This library is really great but there are some bugs with it. When you have sometime I would like you to take a look at this:

http://forum.arduino.cc/index.php?topic=408851.0

For some reason your library is a little "unstable", when you change some lines of code it simply stops working. I also provide you below with a really simple code to use your great library to retrive DMP data from MPU6050 without using interrupt pin. It simply freezes arduino after some time. I already checked with an osciloscope and everything is working fine there is not reason (at the hardware) that could make this freeze happens. Could you please run the code below in your arduino and wait a few seconds? After around 10-30 seconds your arduino will freeze.

#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"
#include "Wire.h"
MPU6050 mpu;
uint16_t packetSize;
uint16_t fifoCount;
uint8_t fifoBuffer[64];
Quaternion q;
VectorFloat gravity;
float ypr[3];

void setup() {

    Wire.begin();
    TWBR = 24;
    mpu.initialize();
    mpu.dmpInitialize();
    mpu.setXAccelOffset(-1343);
    mpu.setYAccelOffset(-1155);
    mpu.setZAccelOffset(1033);
    mpu.setXGyroOffset(19);
    mpu.setYGyroOffset(-27);
    mpu.setZGyroOffset(16);
    mpu.setDMPEnabled(true);
    packetSize = mpu.dmpGetFIFOPacketSize();
    fifoCount = mpu.getFIFOCount();

    Serial.begin(115200);

}

void loop() {

    while (fifoCount < packetSize) {

        //here comes my other code




        fifoCount = mpu.getFIFOCount();

    }


    if (fifoCount == 1024) {

        mpu.resetFIFO();
        Serial.println(F("FIFO overflow!"));

    }
    else{

        if (fifoCount % packetSize != 0) {

            mpu.resetFIFO();

        }
        else{

            while (fifoCount >= packetSize) {

                mpu.getFIFOBytes(fifoBuffer,packetSize);
                fifoCount -= packetSize;

            }    

            mpu.dmpGetQuaternion(&q,fifoBuffer);
            mpu.dmpGetGravity(&gravity,&q);
            mpu.dmpGetYawPitchRoll(ypr,&q,&gravity);            

            Serial.print("ypr\t");
            Serial.print(ypr[0]*180/PI);
            Serial.print("\t");
            Serial.print(ypr[1]*180/PI);
            Serial.print("\t");
            Serial.print(ypr[2]*180/PI);
            Serial.println();

        }

    }

}

hgvk94 · 2016-06-28T16:29:40Z

Hello,

I used to have the same problems. Try running it without the serial
prints.It had worked for me.

cheers and regards

On Tue, Jun 28, 2016 at 9:51 PM, batata004 [email protected] wrote:

@jrowberg https://github.com/jrowberg I never wanted to offend you. I
know you did this library for free and you are contributing a lot with the
community providing it to general use. This library is really great but
there are some bugs with it. When you have sometime I would like you to
take a look at this:

http://forum.arduino.cc/index.php?topic=408851.0

For some reason your library is a little "unstable", when you change some
lines of code it simply stops working. I also provide you below with a
really simple code to use your great library to retrive DMP data from
MPU6050 without using interrupt pin. It simply freezes arduino after some
time. I already checked with an osciloscope and everything is working fine
there is not reason (at the hardware) that could make this freeze happens.
Could you please run the code below in your arduino and wait a few seconds?
After around 10-30 seconds your arduino will freeze.

#include "I2Cdev.h"
#include "MPU6050_6Axis_MotionApps20.h"
#include "Wire.h"
MPU6050 mpu;
uint16_t packetSize;
uint16_t fifoCount;
uint8_t fifoBuffer[64];
Quaternion q;
VectorFloat gravity;
float ypr[3];

void setup() {
Wire.begin();
TWBR = 24;
mpu.initialize();
mpu.dmpInitialize();
mpu.setXAccelOffset(-1343);
mpu.setYAccelOffset(-1155);
mpu.setZAccelOffset(1033);
mpu.setXGyroOffset(19);
mpu.setYGyroOffset(-27);
mpu.setZGyroOffset(16);
mpu.setDMPEnabled(true);
packetSize = mpu.dmpGetFIFOPacketSize();
fifoCount = mpu.getFIFOCount();

Serial.begin(115200);
}

void loop() {
while (fifoCount < packetSize) {

    //here comes my other code




    fifoCount = mpu.getFIFOCount();

}


if (fifoCount == 1024) {

    mpu.resetFIFO();
    Serial.println(F("FIFO overflow!"));

}
else{

    if (fifoCount % packetSize != 0) {

        mpu.resetFIFO();

    }
    else{

        while (fifoCount >= packetSize) {

            mpu.getFIFOBytes(fifoBuffer,packetSize);
            fifoCount -= packetSize;

        }

        mpu.dmpGetQuaternion(&q,fifoBuffer);
        mpu.dmpGetGravity(&gravity,&q);
        mpu.dmpGetYawPitchRoll(ypr,&q,&gravity);

        Serial.print("ypr\t");
        Serial.print(ypr[0]*180/PI);
        Serial.print("\t");
        Serial.print(ypr[1]*180/PI);
        Serial.print("\t");
        Serial.print(ypr[2]*180/PI);
        Serial.println();

    }

}
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#252 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHU5fba5qUzoaqZYvO3ULoG8vJ2uLeH_ks5qQUoegaJpZM4I9cTT
.

batata004 · 2016-06-28T16:42:43Z

I tried it right now and didnt work :( I even tried changing the baud rate and it also didnt work. I think it's not related to Serial but to something in the library cause there is never a buffer overflow when I run the above code in my arduino so the Serial is not causing a significant delay that could cause a problem/overflow. I am pretty sure is something related to MPU6050 DMP library.

batata004 · 2016-06-29T16:42:35Z

@jrowberg please, when you have a time try the code I gave you in your arduino with MPU6050. I am sure it's gonna freeze and I would like to know from you where is the bug of the library so I can fix it on my end.

batata004 · 2016-07-05T21:23:08Z

:( I wish jeff could find the bug in this code

yang614 · 2016-07-07T10:47:21Z

So the line for (; Wire.available() && (timeout == 0 || millis() - t1 < timeout); count++) doesn't work even you specify a value to timeout? Then why write (timeout == 0 || millis() - t1 < timeout) rather than removing it?

batata004 · 2016-07-07T13:08:01Z

@yang614 I changed the line as you said and the bug still happens, arduino freezes. I dont know for sure if it's a timeout problem. Could you please test the code I provide in your arduino amd mpu6050? Other people on forum.arduino.cc could also replicate this bug, that's why I came here to github but unfortunatelly jeff does not look available to help with this

yang614 · 2016-07-11T00:45:39Z

I changed, too. Yes ,it still happens.I am waiting Rowberg to explain it.

batata004 · 2016-07-11T02:03:21Z

yeap, same here. I really hope Rowberg replies us here.

yang614 · 2016-07-11T02:35:28Z

Do you use mag?　I use the HMC5883L with mpu6050 to read the mag raw data and read the pitch yaw roll by DMP is fine. But when I use the mpu9150 to read the the mag data by DMP only , it keeps overflow and freezes soon.

You should change your TWBR =24 to =12 or substitute TWBR to Wire.setclock(400000),if only read data without mag ,mine is working fine with this edition by Jeff Rowberg.

batata004 · 2016-07-11T02:37:48Z

I only use MPU6050 without any magnetometer, and I try to read data from DMP (not raw data). It freezes after a while.

You think chaing TWBR from 24 to 12 should help?

yang614 · 2016-07-11T02:38:42Z

Yes, or Wire.setclock(400000).

batata004 · 2016-07-11T13:59:42Z

I tried it just right now. If freezed using "Wire.setClock(400000);" and also when using "TWBR = 12;". Any suggestion?

jaundice · 2016-07-11T17:31:59Z

A while ago I had issues with FIFO overruns on a 9150 but I can't remember the details. Switching to FastWire fixed it for me.

On 11 Jul 2016 14:59, batata004 [email protected] wrote:

I tried it just right now. If freezed using "Wire.setClock(400000);" and also when using "TWBR = 12;". Any suggestion?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/252#issuecomment-231742469, or mute the threadhttps://github.com/notifications/unsubscribe/AA9a97SsYhZ-M_bsLXiththQS5P6exTfks5qUkxQgaJpZM4I9cTT.

batata004 · 2016-07-11T17:39:46Z

Sir, how I switch to fast wire?

batata004 · 2016-08-23T12:59:51Z

@TMcGahee you certainly have no idea what you are talking about and you surely should delete your reply to this bug report. Read all the thread, I am not using any delay and I know much better than you how important it is to keep the loop fast.

ewerlopes · 2016-10-11T08:41:27Z

@batata004 , any progress on this matter?

batata004 · 2016-10-11T12:51:14Z

I gave up, this library is too buggy in many aspects and Jeff Rowberg does not care about solving these MANY bugs that you can find with a simple search at Google. Also Jeff does not even read these threads.

IMPORTANT: DONT USE JEFF'S LIBRARY FOR ANYTHING IMPORTANT. Sooner or later it will fail and if you are using this library with your quadcopter, robotic arm... STAY AWAY OF IT. You will get hurt and hurt other people. There are serious problems with this library which will, sooner or later, cause you intermitent problems.

jrowberg · 2016-10-11T15:46:46Z

@batata004, please try to avoid sensationalist language with unsubstantiated claims. Yes, I am reasonably certain that the I2Cdev core and especially some of the device libraries are not bug-free. However, they have worked remarkably well with very few changes for literally thousands of people, some of whom have come back to tell me so after the fact (with complete, stable, working project demos).

As noted in my comment from June 28, I2Cdev core code itself does not contain any loops that could lock up the whole system. The Wire library, however, does. This is well-documented and tracked separately. It is not something that I2Cdevlib code can fix, other than switching to a different I2C implementation (which is not a bad idea, but it is outside the scope of this bug report). I still contend that I2Cdev core communication works correctly as long as the hardware is electrically reliable. If the hardware is not electrically reliable, the CPU freeze is because of the Wire library, which has a blocking while() loop and no timeout as documented in Arduino issue #1476.

I have taken the example code that you posted on June 28 and run it with no modifications in the following setup:

Arduino IDE v1.6.11
I2Cdevlib repo pulled from latest Github master branch
Official Arduino Uno R3
GY521 breakout board for MPU-6050
AD0 pin tied to Arduino GND
VCC pin to Arduino 5V (GY-521 has 3.3v regulator on board)
SDA/SCL pins connected to Arduino SDA/SCL correctly
Saleae Logic analyzer monitoring SDA and SCL

Your sketch compiles and flashes correctly. The DMP initialization completes without issue, and the YPR output settles within a few seconds to a stable value. I have left it running for 15 minutes with no problems. It has remained totally stable with no freezes, FIFO overflows, or other problems.

To test, I pulled out the SCL wire to simulate an electrical issue. This (at least this time) caused the SDA line to get stuck low:

The I2Cdev core is not doing this inside its own abstraction code. The GY-521 has 2.2k pull-up resistors on the SDA/SCL lines, so something is driving SDA low during a read operation from the Arduino side. Reconnecting the SCL wire does not resume normal operation, even with all zero data coming back. This suggests that the Wire library got stuck in its blocking while() loop while the MPU-6050 sensor is holding SDA low waiting for more clock pulses, which won't come because the Wire library is stuck. (Maybe. I haven't dug into the Wire library's guts.)

But the main point here is that it worked perfectly until I broke the hardware on purpose.

I will reset the Arduino and let it run for another long while just to confirm this (expected) behavior.

batata004 · 2016-10-11T16:17:02Z

Thanks jeff and I didnt want to offend you. No. I appreciate your help, but I think it would be smart to let people know that your library sometimes crashes. Yes, I executed this same code many times with no problem. But sometimes when I just add some lines of code it gets completely unstable, and after a while it does not generate any other problem.

Jeff, I dont have bad wiring, this is not my case. The wires are very well connected to arduino. I realized this bug happens when you call mpu.getFIFOCount() too many times in small time frame. It almost always freezes at mpu.getFIFOCount() (right when it gets executed). I know that for a fact cause I puted serial.println before and after that function, and it freezes the only the first serial.println.

You library may work fine in a moment, in another it just does not work. Adding some lines make the code break sometimes, and other times dont (there is no conflict between your code and those new lines).

Jeff, I appreciate your attention and efforts into this library but something is not right. Maybe you are right and it's bad wiring, but in my case it surelly is not. I tested this setup in other arduinos and got similar results.

I dont know if you ever heard of SEBRAE here in Brazil. It's an education institution "for free", with small fees. I know at least 2 good friends which are teachers of this institution in electronics and also confirmed the problem I was facing. It was them who made me come here and report this.

I tried to report this problem in many different foruns and in almost all cases, in the middle of the thread, other people confirmed what I said and had the same problem with different setups.

If you think this problem happens of because of some lines of I2C getting LOW, why cant you setup and interrupt in your code to check if the line is LOW for too long and maybe reset the device it that timeout happens? I never used an original arduino, I always used clones, maybe some poor build in those clones cause this problem?

Sorry if I disrespected you, you are a nice guy who devoted lots of time to this library however I think, IMHO, that it's not safe using your library in quadcopters, robotic arms... someone could get seriously hurt.

KyleMercer · 2016-10-20T23:22:41Z

@batata004 I don't think you are quite getting the point Jeff is making. The problem is not with his library, but with the Arduino Wire library itself that is part of the Arduino IDE. More specifically it is the two-wire interface (TWI) library that the Wire library calls to handle I2C communications.

I stumbled upon this discussion looking for an alternative implementation of an I2C library for a unrelated device I am using and can confirm that any device that calls the Wire library will suffer the same issue you are talking about.

While loops are used in the TWI library for communication, and as a result, the code can block all other functions on the Arduino while it is waiting infinitely in the TWI while loop. Jeff demonstrated the infinite loop by pulling out the SCL wire from his hardware. Internally, the TWI library provided by Arduino waits for a response from the sensor that is never coming because the physical wire is removed.

While your friends at SEBRAE confirmed the behavior, like you they have wrongly assumed it is due to Jeff's code. If you took a different I2C sensor with a library written by a different person (such as the one for the sensor I am using) and pulled a wire, it would behave the exact same way.

As for why can't Jeff put an interrupt in his code to check if the line is LOW for too long, the library is blocking anything from happening (Which is why everything stops). The Arduino environment is not a Real-Time Operating System (RTOS). The issue is outside Jeff's code.

I hope this clarifies the issue.

batata004 · 2016-10-20T23:46:37Z

@KyleMercer you made it very clear, but it still does not explain why reading data from BMP180 using any library around will never hang, never. But as soon as I disconnect BMP180 and connect MPU6050 problems start to happen. It may be a problem in the WIRE implementation, ok! Maybe for some reason MPU6050 has some problem (I already tried at least 5 different modules from 3 different sellers in the last year or so) with the hardware, I dont know. I can only say that this problem only happens with me:

WHEN using MPU6050 with jeff's library
WEN I try to read veery fast data from MPU6050, if I read data once every 100ms, it all works fine
in unprecitable times, I cant be sure that it will happen now, but it will certainly happen at some moment

Anyway, you were all very clear and made a point. Maybe it's wire.h implementation that is faulty!

KyleMercer · 2016-10-21T02:09:44Z

@batata004 Thanks for your response. I hope that no offence was taken. The issue I am having is actually related to the BME280, a distant relative of the BMP180 sensor, and communications via TCP/IP. My hardware and project is quite different from what you are discussing, and I do not use the MPU6050. From my quick Google search it sounds like the sensor does a lot, and making it work with other I2C hardware is tricky. I wanted to offer some feedback only because I noticed the strong language in your reply to Jeff.

I did a quick test with my project, in which the BME280 is the only device communicating via I2C. My microprocessor is an ESP8266 (Which is quite a bit faster than the Uno) and I am using a common industrial protocol over TCP/IP. I have some software that is polling the ESP8266 every second, and I am actively debugging using the serial interface, so there is additional work being done by the system. I pulled one of the wires, and the system kept working. I put the wire back, still no problems. I tried this a couple more times, randomly, and finally the system stopped working. I am only asking for one value via I2C and one value over the industrial communication channel, so I would guess that if I increased the amount of data through the different interfaces, the problem might start to happen more often.

Anyways, I hope that you can find a solution to the problem you are having. I thought I would share what I have experienced. Take care!

batata004 · 2016-10-21T11:33:35Z

@KyleMercer no offence taken :) Glad to know your case, indeed it looks even more a problem with I2C protocol itself than with the jeff's library. What you said is exactly what happens to me, randomly/intermitently problems (as you removed the wired a few times).

Anyway, I hope jeff or somebody here with great knowledge in this subject could file a feature request/bug report at Arduino community so they can bring some light to this and solve this problem.

salute2vishal · 2016-11-21T14:50:26Z

@batata004
Hey did you find the solution to the problem ? I am also facing the same issue, sometimes the library gets stuck at fifo count function .

Astro-Johnny · 2017-05-11T19:42:58Z

Hello people! I stumbled upon this topic while searching for info about MPU6050 latching SDA down. For the record -- I'm having the same latching problem with i.MX6 SoC running Linux. Incidentally, it also always happens getting the FIFO count, as far as I've tested at the moment (but not always on the same byte).

Anyway, the reason I'm posting this, is -- given the number of hits in Google -- I have good enough reason to believe this bug is due to MPU6050 chip itself. The variance of when it crashes is highly variable though.

batata004 · 2017-05-11T19:56:52Z

@Astro-Johnny would you mind telling where did you by you MPU6050? Mine I bought from a good reputation store that is a college for studants learning arduino. I think you are correct, there is some sort of problem with the chip itself that causes this problem BUT the Wire library should be able to handle this right, I think the problem is with WIRE and MPU6050 library, none of them are knowing how to handle some unexpected behaviour (or now "expected behaviour" as many reported it) with the chip. Sometimes one of the communication lines dont go back to HIGH or something like that... JEFF'S library and WIRE.H library should know bettter how to handle intermitent connection problems, maybe using timeouts.

Astro-Johnny · 2017-05-12T06:03:14Z

@batata004

would you mind telling where did you by you MPU6050?

Not at all. I bought two units from Drotek -- both exhibit the same behaviour... much to my dismay.

BUT the Wire library should be able to handle this right, I think the problem is with WIRE and MPU6050 library, none of them are knowing how to handle some unexpected behaviour (or now "expected behaviour" as many reported it) with the chip.

No, not really. MPU6050 latching SDA low is a violation of I²C protocol. Thus, this means undefined behaviour for the library. It really is up to you -- as system engineer -- to handle such situations.

There is no universal way to unlatch such a chip although a common technique is disabling I²C, sending 9 clock cycles over SCL pin (as a GPIO) and reenabling I²C mode if SDA unlatches. (Or resetting the offending chip, if possible.)

Regarding, the situation with Wire -- it would certainly be nice if it could detect a SDA latch condition as it currently just freezes preventing further handling. This is in fact an oft requested feature. Of course, this requires use of a Timer which is a precious resource on an Arduino. Either way, in my humble opinion, the only correct way for Wire to go about it -- if it were to implement timeouts -- return an error, and let the designer handle it. @jrowberg may (or may not) then choose to implement quirky chip handling, but currently his hand are tied.

One last note -- please understand that this is not a bug, you've filed a feature request. I also encourage you to try patching the code yourself and share your results (should you choose to). This is an open-source community. Weee! 😃

batata004 · 2017-05-12T07:42:14Z

@Astro-Johnny I agree with everything you said :) Only one single thing that I not agree: it's of course the programmer/engineer responsable for mantaining and keep its code base working. BUT there is a big BUT here: arduino freezes when this problem that I reported here happens. How can I try to fix this problem if arduino freezes? The only possibility to me try to fix this would be to change the implementatino of Jeff's code and Wire.h.

You can imagine that I am not too inside those 2 libraryes, I am not developing a veeery simple head tracking mechanism while I would also have to deeply study WIRE.H and Jeff's library. I dont even have a scope!! :(

I think it's in the community's best interest that those people able to do that, if they feel happy about that, that they should help. It's not a reasonable argument that I should try to fix the problem, if the owner of the library is having a difficult time trying to solve this problem, who am I to try to solve it?

I know this is how open source works, and I love everything about it. But, IMHO, this is indeed a bug. If the library is told to do something AND it does not, it's a bug.

If a library gets responsable to provide you ACCEL/GYRO data and it freezes once in a while, it's not a feature request that this freeze stops happening, it's a bug.

Nobody comes to a bugtracker and says "Please, I love your library but sometimes it freezes, would you mind adding a feature request that, if possible, can you please, please, LITTLE PLEASE, stop your library's code from freezing and crashing?".

As I see it's a bug, plain and simple bug. But HEY I am happy we disagree on that, otherwise this community would never get so big and raise so many important discussions if everybody had the same ideas! \o/

j03m4r13 · 2017-06-29T05:14:26Z

I have similar situation. My current setup includes a generic MPU6050 (probably a GY-521) and a Dual h-bridge motor driver board and Arduino Pro mini running at 5volts/16mhz. I am using Jeff's library and it works well without the motors running. I am using DMP to get the values from the Gyro. However problems seemed to come when the motors were turned on. At first I tried to eliminate the problem's cause. My first guess is that it's due to the motor's noise that's causing the MPU's erratic behavior or freeze. When running the MPU with the Motors turned on, the longest I can get is about 15 seconds and it seems I am blocked somewhere in an infinite loop. The motors are still running but I could not make it react using the IR sensors and if I pull off the MPU during the run, the functionality of my motors' feedback system resumes. So I suspect that it's the motor driver that's causing the erratic behavior of the MPU. But here's the interesting thing, when I used the code from here https://playground.arduino.cc/Main/MPU-6050(Without using Jeff's library), in fact it's also using the Wire.h. I integrated my motor functionalities into the new sketch to see if both MPU and the motor runs, then I was able to make it work and it runs indefinitely without MPU readouts freezing. In conclusion to this finding, it's Jeff's library that's causing the problem.

batata004 · 2017-06-29T12:40:45Z

@j03m4r13 really interesting result and it matches what I initially thought: jeff's library has a problem. I was induced to believe it was wire.h library fault but that cant be possible cause when I extract data direct from the sensor using only wire.h my arduino never freezes. it only freezes when I use jeff's library to get dmp data (that I cant get using only wire.h).

Hope jeff investigate this better.

jrowberg · 2017-06-29T14:26:14Z

This is a good data point, but it does not conclusively indicate a problem in I2Cdevlib code. The code from arduino.cc example, for instance, does not use the DMP, so the MPU itself is operating without making use of its internal processor. Since this issue has focused on failure case when the DMP is active, that's a significant difference. All comments on this issue referring to raw data access only (no DMP) indicate that the I2Cdevlib code is rock solid. Unless the freezing problem also happens when using I2Cdevlib code for only raw accel/gyro readings, @j03m4r13's case does not actually add new information to what we have already seen.

Also, the I2Cdevlib code adds some (very) small processing overhead to each I2C transaction since it is another layer of function call abstraction around the core TWI hardware. Given the seemingly random nature of the freeze failures, it is possible that unpredictable small timing differences have an effect on whether the failure case occurs. If this is happening, it still does not necessarily mean that I2Cdevlib code has a defect, but only that I2Cdevlib code increases the probability of conditions necessary for the problem to occur.

To get back to the fundamental point here:

MPU6050 latching SDA low is a violation of I²C protocol, as @Astro-Johnny pointed out.
The Wire library has an internal blocking infinite while loop with no timeout/cancel mechanism.
I2Cdevlib code has no blocking infinite while loops itself, and cannot break out of the one in the Wire library.

In other words:

The MPU6050 is doing something it shouldn't, and
The Wire library does not accommodate this behavior cleanly, and
I2Cdevlib cannot fix this without requiring a dedicated hardware timer or else rewriting or replacing the Wire library itself, which is technically possible but outside the current scope of the project and would necessarily break compatibility with current and previous Arduino installations.

I am all for clean, bug-free code, but I have yet to identify any potential root cause(s) for this behavior in I2Cdevlib. The true root cause appears to be in the MPU itself, or might be worked around (or at least detected) with a Wire library improvement or kludge like testing millis() inside the while loop. Detecting and mitigating the problem at the I2Cdevlib layer while still using the Wire library as-is would require a prohibitively complex and resource-intensive addition of timers and interrupts. This type of fix would be more suitably (and just as easily) added to the main application logic rather than the I2Cdevlib code, since 99% of the time it would be irrelevant for other I2Cdevlib users.

batata004 · 2017-06-29T17:07:12Z

@jrowberg you are always very clear and informative. All your conclusions and assumptions are correct (IMHO) but would you mind explaning why when I grab data from the MPU6050 (raw) it never freezes and when I grab using your great code to access DMP it intermitently is freezes?

For example, the code below works PERFECTLY. Never freezes, is super reliable and I never never never had any problem when using it.

#include "Wire.h"
//Endereco I2C do MPU6050.
const int MPU=0x68;  
int ax,ay,az,gx,gy,gz,temperatura;

void setup() {

    Serial.begin(115200);
    
    Wire.begin();
    Wire.beginTransmission(MPU);
    Wire.write(0x6B); 
    Wire.write(0); 
    Wire.endTransmission(true);

}

void loop() {
    
    Wire.beginTransmission(MPU);
    Wire.write(0x3B);
    Wire.endTransmission(false);
    
    //Solicita os dados para o sensor.
    Wire.requestFrom(MPU,14,true);  

	//Lê os dados do sensor.
    ax = Wire.read()<<8|Wire.read();  //0x3B (ACCEL_XOUT_H) & 0x3C (ACCEL_XOUT_L)     
    ay = Wire.read()<<8|Wire.read();  //0x3D (ACCEL_YOUT_H) & 0x3E (ACCEL_YOUT_L)
    az = Wire.read()<<8|Wire.read();  //0x3F (ACCEL_ZOUT_H) & 0x40 (ACCEL_ZOUT_L)
    temperatura = Wire.read()<<8|Wire.read();  //0x41 (TEMP_OUT_H) & 0x42 (TEMP_OUT_L)
    gx = Wire.read()<<8|Wire.read();  //0x43 (GYRO_XOUT_H) & 0x44 (GYRO_XOUT_L)
    gy = Wire.read()<<8|Wire.read();  //0x45 (GYRO_YOUT_H) & 0x46 (GYRO_YOUT_L)
    gz = Wire.read()<<8|Wire.read();  //0x47 (GYRO_ZOUT_H) & 0x48 (GYRO_ZOUT_L)
    
    Serial.print("ax/ay/az/gx/gy/gz/temperatura\t");
    Serial.print(ax);
    Serial.print("\t");
    Serial.print(ay);
    Serial.print("\t");
    Serial.print(az);
    Serial.print("\t");
    Serial.print(gx);
    Serial.print("\t");
    Serial.print(gy);
    Serial.print("\t");
    Serial.print(gz);
    Serial.print("\t");
    Serial.print(temperatura/340 + 36.53);
    Serial.println();
    
	delay(100);
    
}

If there was any problem with MPU6050's processor or some timing issue, it would create some intermitent problem when also using the code above. On the other hand, as soon as I use your demo code (the one that extracts data from DMP) problems start to happen. I never used your getMotion6 code to check if the problem also happens cause if I have to extract raw data I prefer doing so with the minimum of abstraction as possible, using the pure Wire.h library and notihng else.

I really think jeff you could get some cheap MPU6050 from china (clone ones) with also an arduino (my is nano clone) and simulate the problem. I think that if you could see the problem by yourself you would be as frustrated as any other person that finds this problem.

I also have to say that MOST people that play around with arudino (I think that most of the people really) are totally beginners and enthusiatics. They will not report any bug or problem, they will think they are doing sometihng stupid and will give up. So I am pretty sure this problem is under reported because people have no idea wha they did wrong AND EVEN IF THEY DIDNT DO ANYTHING WRONG people will always tell those beginners that they are inserting code that takes too long to execute (like delay) and that's the person's fault.

jrowberg · 2017-06-29T17:31:36Z

HI @batata004,

but would you mind explaning why when I grab data from the MPU6050 (raw) it never freezes and when I grab using your great code to access DMP it intermitently is freezes?

This is exactly the problem that nobody can explain (so far).

If there was any problem with MPU6050's processor or some timing issue, it would create some intermitent problem when also using the code above.

I don't think this is true. The issue seems to concern the MPU's behavior when the DMP is in use. By all accounts, the fact that it works perfectly when you use native Wire API calls to get raw data but it randomly freezes when using I2Cdevlib code to use the DMP is not because you're using I2Cdevlib code in the failing case, but rather because you are using the DMP in the failing case. I fully expect that if you did test the getMotion6 example with your hardware, it would work fine.

Likewise, if you mimic the DMP initialization routine yourself using Wire and not I2Cdevlib, and then read DMP packets from the FIFO also using Wire and not I2Cdevlib, I expect your hardware will fail the same as it is doing now.

It may be worth rolling my own I2C/TWI implementation with timeout support, or switching the underlying implementation to something like NBWire. However, I'm not sure it is worth spending a lot of time specifically troubleshooting a case that only appears to occur with clone Arduino or especially clone MPU parts. If the problem originates inside the MPU, then there is no guarantee that we could fix it even if we could detect it and avoid a blocking case. That would, at least, allow triggering an MPU reset instead of just freezing the entire CPU though.

batata004 · 2017-06-29T19:07:11Z

@jrowberg thanks man! Indeed, when DMP is active maybe something weird happens with the module. Maybe it's enabling the DMP that causes the problem in the module. I just dont agree with your argument that this problem "only" appears with clones. Recpectfully, I assure you that here in Brazil 90% of people buy clones: as for arduino as for mpu6050. Maybe in your country people can afford original ones but here I am pretty sure no more than 10% of people use original/certified hardware.

Anyway, I think if more people had time to investigate why their arduinos freezes more people would join me complaining about this problem. And maybe you would be convinced the amount of people that is having to deal with this.

I dont know much about how your library works (nor wire.h) but I think using some type of timeout would fix the problem easily. If the DMP does not respond for (example) 100ms, you output some message and keep the user code running. Or maybe you could reset the module and initialize it again if the response is taking too long. I have no idea if this is easy or hard, but if someday you find some spare time I am pretty sure this implementation would save loooots of time of many people!

Despite what I said I respect you already did an AMAZING library for all the community! I wish there were more people that know deep about this and would be willing to help you!

tinkerspy · 2017-07-02T20:03:46Z

It's a pity. The library looks really nice, but I can't use it when it's crashing. The combination of hardware I'm using is the GY-521 (chinese clone) and a Teensy 3.1 (no chinese clone). There's an alternate i2c library for the teensy's called i2c_t3. Could that be a solution to this problem?

Perhaps the following options could help?
I2C_AUTO_RETRY
Wire.setDefaultTimeout(timeout);

Astro-Johnny · 2017-07-06T10:35:23Z

@tinkerspy the library isn't crashing per se -- it's rather the chip is crashing/misbehaving which the Wire is not made to cope with. The "i2c_t3" library you've mentioned looks to me like a Wire replacement for Teensy, which implements timeout and bus recovery (by pushing out 9 dummy clocks) (yes, it's the I2C_AUTO_RETRY you mentioned). As such I find it's entirely feasible to use "i2cdevlib" on top of "i2c_t3" with perhaps little modifications of the former. @jrowberg to confirm.

I cannot say for sure if your MPU6050 will misbehave (you should test it), but you must understand implications if it does. Primarily it means during a "latchdown event" you may lose some sample points, or at very least get them late if you're using hardware FIFO. Whether this is a problem to you depends on your application (e.g., a drone will be very sensitive to such hiccups in data).

Speaking of unlatching MPU6050 with dummy clocks -- yes it works. Well it worked for me.

of course you will probably want to use shorter timeout than 1 second.

tinkerspy · 2017-07-14T19:49:43Z

Thanks Johnny,

Apparently my hangs were caused by bad connections. Since I fixed them I haven't seen them anymore. When I had them I also saw them with different (non-DMP) MPU code. When I changed that to the t3* library the hangs disappeared but I didn't receive any data either.

Now busy with pid-tuning ;-)

Rgdz.

mekanixms · 2017-12-06T21:02:36Z

Got into this issue myself today. The behavior, in this case, is: all works well till I disconnect the usb cable from the board. Several seconds later it freezes. If I let it stay for a while starts to work again for a few cycles and stops again, this repeats randomly, annoying

mekanixms · 2017-12-08T08:58:53Z

Solved, it was something I did wrong with the wiring; when I power separately the servos and arduino (with the usb cable) works like charm.
Many thanks Jeff Rowberg, keep up with the good work!!

cztay · 2017-12-09T14:33:20Z

I face the FIFO overflow problem

Astro-Johnny · 2017-12-11T07:10:13Z

@tcz3103 this issue is not about FIFO overflow. You may want to check if issue is not filed for your problem already (and file a new one if it isn't). Or, if you find this is the relevant issue, please provide more information. E.g., does your MPU6050 latch SDA? Are you using DMP? What platform you're on? Etc.

m-stan · 2018-02-08T10:29:10Z

I am using Jeffs library to read DMP data from MPU6050 without interrupts since I have other timing critical parts in my application. Basically, my code is very similar to what @batata004 has posted above.
Code for DMP without interrupt

Arduino Pro Mini 3.3V as well as Arduino Nano clones are used.
As observed by others my Arduino also "freezed" after few seconds or minutes with my setup. The freeze can be forced to happen more quickly if some operations in the loop take some time.
E.g. if I change

while (fifoCount < packetSize) {
    //here comes my other code
    fifoCount = mpu.getFIFOCount();
}

to

while (fifoCount < packetSize) {
    //here comes my other code
    delay(10);
    fifoCount = mpu.getFIFOCount();
}

my Arduino freezes after approx. 2 seconds.

I have found that sometimes the fifoCount is not read correctly or it is read while the FIFO is filled. I have seen that fifoCount is set to e.g. 82 bytes, 115 bytes or other values. The packet size of DMP data is 42 bytes, so we would like to see multiples of that.

In the code posted above the following happens:

while (fifoCount < packetSize) {
        //here comes my other code
        fifoCount = mpu.getFIFOCount();
}

reads fifoCount until a value > 42 is reached. Here it happens that values which are no multiples of 42 are read. Lets assume we read "82" here for the current number of data bytes in the FIFO.

Next the while loop is escaped. In the if-statement it is checked whether we have a FIFO overflow. We have read 82, which is smaller than 1024 and thus no buffer overflow. Continue to "else" branch. In the statement

if (fifoCount % packetSize != 0) {
    mpu.resetFIFO();
}

our fifoCount (82) is not a multiple of 42, thus the FIFO is reset. BUT: the variable fifoCount still has the value "82" and never gets updated again! after the resetFIFO() we start at the very beginning of loop() where fifoCount (still=82) is not smaller than packetSize and thus fifoCount = mpu.getFIFOCount(); is not executed.

Thus, for me changing

if (fifoCount % packetSize != 0) {
    mpu.resetFIFO();
}

to

if (fifoCount % packetSize != 0) {
    mpu.resetFIFO();
    fifoCount = 0;
}

solved the "freezing" issues of MPU6050 in my application. At least for the DMP without interrupt version of reading data from MPU6050 the bug was IMHO in the loop() and not in the libraries.

Sorry if this was already known but it took me some days to figure it out.

Astro-Johnny · 2018-02-08T12:23:00Z

@m-stan:

The freeze can be forced to happen more quickly if some operations in the loop take some time.

This is something I've observed as well. The freezing seems to be affected by timing, which just strengthens my hypothesis that there is a bug with MPU6050 itself (i.e., its firmware or/and circuitry).

I have found that sometimes the fifoCount is not read correctly or it is read while the FIFO is filled. I have seen that fifoCount is set to e.g. 82 bytes, 115 bytes or other values. The packet size of DMP data is 42 bytes, so we would like to see multiples of that.

That's why you want an interrupt signalling when to read. 😃 Or if not, and you're sure of data validity, read off the data in packetSize chunks and let the remainder bytes in FIFO for the packet to be reconstructed a little later. It is a FIFO after all.

batata004 · 2018-02-08T12:53:44Z

@Astro-Johnny I totally agree with you regarding what could be causing the freeze BUT I think Jeff's library could implement some method to "failsafe" instead of freezing. Imagine yourself flying a drone and have MPU6050 freezing your arduino

Also I cant be pretty much sure that the firmware of mpu6050 is faulty, maaaany industry leaders drone builders use mpu6050 and surelly they think it is reliable. So I think that jeff's library has something to do with this bug.

AlexM19 · 2018-03-01T16:21:52Z

@batata004 I have to say, I highly dislike your attitude. To summarize, you have unoffcial hardware, you admitted having limited knowledge of the library you use and the I2C (TWI) protocol, you did not provide anything concerning your hardware setup and wiring and yet you insist in making claims about
i2cdevlib reliability even after numerous people, including mr. Rowberg himself, has pointed to you the potential source of your issue.

Astro-Johnny scope out the faulty sequence and finaly proved that the MPU keep the data line latch low. He also demonstrated how you could unlatch the data pin by forcing clock signal. This has nothing to do with i2cdevlib and rather is linked to flemsy hardware and TWI driver implementation.

I make a living developping embedded software. This is a common issue I had with numerous sensor. The sensor get stuck in is state machine and does not complete the I2C transaction hence keeping the data line low. I have implemented multiple I2C driver for a variety of mcu and now I always implement a recovery sequence in which the mcu take control of the I2C line and bit bang is way out forcing either a stop condition or a software reset on the sensor (see any I2C protocol documentation for this).

Now as mr. Rowberg told you, it would be difficult to stay compatible with arduino platforme using is own TWI driver, not impossible, but not in the scope of this library. So you are left with these two choices:

Buy thrusted hardware.
Fix the WIRE library.

Also I would like to remind you that this is free open-source software. No one owes you anything. If you are so certain of the bug source then fix it yourself! Best luck with that!
Regards,
Alex

batata004 · 2018-03-01T16:27:30Z

@AlexM19 I have to say, I highly dislike your attitude.

Hundreds of people are facing the same problem, surely it's my "unofficial" hardware which is the root of the problem. Surely I am the curlprit.

AlexM19 · 2018-03-01T16:42:52Z

Well if there is a bug in the firmware of the MPU and everyone is using the arduino WIRE library then yes they will all be facing the same issue so what is your point exactly?

I never said you were personally responsible for this issue. I said that you make claims that you cant prove and this is rather annoying, especially when people point out the source of the issue.

A word of advice, dont buy cheap hardware if you have not the knowledge nor the equipement to troubleshoot the thing if there is a problem.

batata004 · 2018-03-01T17:11:10Z

@AlexM19 You dont live here in brazil, the cheap parts you buy in US are expensive here, and the expensive parts you buy in US you rarely can buy here in brazil being able to trust the seller.

LOTS of brazilian are using the "regular" MPU6050 sold in the internet. We have no way to tell if it's good or bad stuff. And even if I pay 10x what it cost to you in US I wont be able to tell if the product was "original"/"certified" cause most sellers hide the origin of the products to avoid taxes.

jrowberg · 2018-03-01T17:12:39Z

I appreciate the comments from those vouching for the integrity of the I2Cdev library, and I also appreciate the frustration that comes from trying to use what should be a reliable device and observing mission-critical failures. However, I think this issue should be closed, or at least have the discussion locked, because it's not going to solve anything.

Let me recap the findings:

The peripheral (MPU-6050 in this case) is behaving in way that is disallowed by the I2C spec. This is not a bug in the I2Cdevlib code.
The underlying I2C/TWI communication layer (Arduino Wire library in this case) contains a blocking while loop that assumes all peripherals will follow the I2C spec. This is not a bug in the I2Cdevlib code. It's not even a bug, exactly, in the Wire library; however, it is a real limitation.

In light of this, there are a finite number of options:

Use a sensor that doesn't break the spec. This is not suitable for those who need the MPU-6050 for whatever reason.
Patch the Wire library locally with the addition of read timeouts. This is possible, but it requires extra effort for each user. Also, it is strictly outside of the scope of the I2Cdevlib project.
Improve the Wire library officially by implementing timeouts and submitting a pull request. This is an ideal solution, but it requires a lot of agreement from many people on the Arduino project. It too is outside of the scope of the I2Cdevlib project.
Implement a custom TWI/I2C communication layer with timeout support. This could be done within the I2Cdevlib project, but it would necessarily mean that projects using I2Cdevlib and its custom TWI/I2C layer could no longer use Wire, making it somewhat restrictive. This solution would fairly be considered a new feature, not a bugfix, as it is not actually fixing any bugs in the I2Cdev code.
Implement a hardware timer/watchdog to interrupt the while loop if needed. This is theoretically possible as well, but it requires using on-chip resources that are already quite scarce in order to solve a corner-case failure triggered by an outside peripheral device behaving badly. This could be added to your application logic, but I would never want it to be part of mainline I2Cdev code.

All further effort towards solving this should be directed at patching the official Wire library to include cross-platform timeout support, as this would add real value and address the pain points that many people are experiencing.

Koepel mentioned this issue Aug 20, 2016

Wrong use of Wire library #265

Open

zhudi0609 mentioned this issue Oct 21, 2016

i2cdevlib的bug你们团队遇到过么 open-robot/ArduinoFirmware#2

Open

jrowberg changed the title ~~Serious bug at Jeff Rowberg library with MPU6050 at Arduino~~ MPU6050 with DMP active hangs indefinitely using Arduino Wire library Jul 16, 2017

tobozo mentioned this issue Aug 28, 2017

wire.available returns 0 when reading mpu6050 fifo espressif/arduino-esp32#594

Closed

ifrew mentioned this issue Dec 14, 2017

i2c Write Issue espressif/arduino-esp32#834

Closed

Repository owner locked as too heated and limited conversation to collaborators Mar 1, 2018

wmarkow referenced this issue in wmarkow/Arduino Mar 29, 2018

arduino#1476 Add timout in twi_stop(void) method.

afc25a6

MPU6050 with DMP active hangs indefinitely using Arduino Wire library #252

MPU6050 with DMP active hangs indefinitely using Arduino Wire library #252

Comments

batata004 commented Jun 24, 2016

bishwa9 commented Jun 27, 2016

batata004 commented Jun 28, 2016

jrowberg commented Jun 28, 2016

batata004 commented Jun 28, 2016

hgvk94 commented Jun 28, 2016

batata004 commented Jun 28, 2016

batata004 commented Jun 29, 2016

batata004 commented Jul 5, 2016

yang614 commented Jul 7, 2016

batata004 commented Jul 7, 2016

yang614 commented Jul 11, 2016

batata004 commented Jul 11, 2016

yang614 commented Jul 11, 2016 • edited Loading

batata004 commented Jul 11, 2016

yang614 commented Jul 11, 2016

batata004 commented Jul 11, 2016

jaundice commented Jul 11, 2016

batata004 commented Jul 11, 2016

batata004 commented Aug 23, 2016

ewerlopes commented Oct 11, 2016

batata004 commented Oct 11, 2016

jrowberg commented Oct 11, 2016

batata004 commented Oct 11, 2016

KyleMercer commented Oct 20, 2016

batata004 commented Oct 20, 2016

KyleMercer commented Oct 21, 2016

batata004 commented Oct 21, 2016

salute2vishal commented Nov 21, 2016

Astro-Johnny commented May 11, 2017

batata004 commented May 11, 2017

Astro-Johnny commented May 12, 2017

batata004 commented May 12, 2017 • edited Loading

j03m4r13 commented Jun 29, 2017 • edited Loading

batata004 commented Jun 29, 2017

jrowberg commented Jun 29, 2017 • edited Loading

batata004 commented Jun 29, 2017 • edited Loading

jrowberg commented Jun 29, 2017

batata004 commented Jun 29, 2017 • edited Loading

tinkerspy commented Jul 2, 2017

Astro-Johnny commented Jul 6, 2017 • edited Loading

tinkerspy commented Jul 14, 2017

mekanixms commented Dec 6, 2017 • edited Loading

mekanixms commented Dec 8, 2017

cztay commented Dec 9, 2017

Astro-Johnny commented Dec 11, 2017

m-stan commented Feb 8, 2018

Astro-Johnny commented Feb 8, 2018

batata004 commented Feb 8, 2018

AlexM19 commented Mar 1, 2018

batata004 commented Mar 1, 2018

AlexM19 commented Mar 1, 2018

batata004 commented Mar 1, 2018 • edited Loading

jrowberg commented Mar 1, 2018 • edited Loading

yang614 commented Jul 11, 2016 •

edited

Loading

batata004 commented May 12, 2017 •

edited

Loading

j03m4r13 commented Jun 29, 2017 •

edited

Loading

jrowberg commented Jun 29, 2017 •

edited

Loading

batata004 commented Jun 29, 2017 •

edited

Loading

batata004 commented Jun 29, 2017 •

edited

Loading

Astro-Johnny commented Jul 6, 2017 •

edited

Loading

mekanixms commented Dec 6, 2017 •

edited

Loading

batata004 commented Mar 1, 2018 •

edited

Loading

jrowberg commented Mar 1, 2018 •

edited

Loading