new verison of MPU6050_DMP6 hangs #13

wolfmanjm opened this Issue Jun 13, 2012 · 11 comments


None yet

2 participants


I made the recent changes to MPU6050_DMP6.ino, change 3af4d4a specifically changing the interrupt to

attachInterrupt(0, dmpDataReady, RISING);

Now it will hang in this line..

while ((fifoCount = accelgyro.getFIFOCount()) < 42);

I put a timeout in this loop and reset the fifo on timeout and it will timeout after several hundred readings very repeatably.

   int cnt= 0;
    while ((fifoCount = accelgyro.getFIFOCount()) < 42){
            if(cnt++ > 100) {
                    Serial.println("Fifo timeout");

Also the data returned prior (and post) to the timeout is incorrect, the yaw pitch roll are changing randomly are not correct.

Reverting to the older version all works well although I notice that quite frequently fifo < 42 when tested but that does not seem to hurt anything as it just waits for the next interrupt and gets it ok.


I also went back to the older version (prior 8395ff4) and just changed the interrupt from CHANGE to RISING and I get the same random incorrect values and frequent pauses.


The RISING interrupt detection should be correct based on the behavior of the interrupt pin, though I have had random issues in another unrelated sketch while using it (and CHANGE appeared to work, so I instinctively went with that option at first). However, I have a thought about what would cause it to hang in that part of the loop: the FIFO count is a 16-bit value, but "fifoCount" is declared as a uint8_t. If you change that to "uint16_t" instead, does it still hang? The comparison is only going to pay attention to the first 8 bits of getFIFOCount() otherwise--a possibility I overlooked.

To be honest, I'm not sure why the old sketch even worked right because of how broken the underlying multi-byte read was in I2Cdev.cpp (which I would recommend updating if you haven't). The Arduino Wire library has a fixed maximum buffer size of 32, and requesting 42 bytes all at once results in very unpredictable behavior.

I hope to have some significant structural and stability changes pushed up to the site for the MPU in the next few days.


Seems I was already using the latest I2CDEV.cpp as you must have fixed that issue a while back. and there are no changes showing at present. So th eold sketch plus new I2Cdev seem to work fine.

I'll try your suggestion about fifo size.


Ok changing fifoCount to uin16_t solves the hang/timeout, however the results I get back are random angles.
Even if I change the interrupt to CHANGE I still get random results. So I guess its not the interrupt level in this case.

BTW all the angles are totally random seemingly.


I also see the fifoSize continously increasing on every read until it hits 1024 then it pauses briefly and reads 42 bytes again and continues. Next size is 52 then 62, 72 etc seems each read the fifosize increments by 10.


Which would explain the garbage I am reading, The first read after the wrap at 1024 is correct the subsequent ones are wrong. Presumably the valid 42 bytes to read are not at the start of the fifo anymore. The old version always read a fifoSize of 10 then skips that and then reads a fifo size of 42 and reads correct data, then next rads 10 and skips then reads 42 etc.


I just looked at the I2Cdev.cpp/.h on the repository and they are inexplicably NOT the newest versions. I honestly thought I committed those changes; you're suffering from the 32-byte TWI buffer limit without the solution I added this past weekend; give me a couple of minutes and I'll push the new changes up. Sorry about that!

Let me know if the fix takes care of your problems, both the hang and the data validity.


Ok, I wonder if that will fix the fifoCount incrementing? Right now it is overflowing the the fifoBuffer which is set to 128 and it is reading more and more data each frame until it hits 1024. Maybe a check for fifoCount > 128 should be made to make sure it doesn't overflow the buffer?

I can't see why there is a difference in the fifoCount behavior between the old and new, I did a diff and other than the interrupt level change and the zeromotion detect setting I see no other setting differences that would account for the fifoCount increasing every frame.

If the fifoCount is > 42 are the readings always the first 42?


Sorry for the delay here; I'm in the process of rebuilding my system on a brand-new SSD, and I didn't realize my git client would take so long to do. It should be done soon.

With the code you're using, I believe it does always read only the first 42 bytes. It only waits for the FIFO count to be reported as >= 42 to make sure it has a full packet available. If the interrupts are firing and being handled fast enough, this works fine. However, it also does require you to read all 42 bytes--the whole packet's worth of data. Since the I2Cdev implementation is only able to read 32, you're left with 10 remaining bytes, which is why it keeps growing usually by increments of 10.

This behavior is to be expected with a broken FIFO-reading function; there really aren't significant differences between the two sketches you're running, which is why when I discovered the 32-byte limit, I was astonished that the original sketch worked at all. I think there must have been some very lucky coincidence of timing involved, or more likely that the CHANGE interrupt made the FIFO check + read fire twice for every interrupt (once on RISING and once right afterward upon reading the INT_STATUS register, which clears the interrupt pin).

Git is still building here...waiting...yeesh.


Okay, FINALLY got it compiled, installed, setup, and the I2Cdev.* changes are pushed. Try that.


Ok that fixed it, Many Thanks!!

Now I need to figure out if that was what was causing my App to act flaky ;)

@wolfmanjm wolfmanjm closed this Jun 14, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment