8 years ago.

mbed freezing after taking a few samples

Hi there! I am rather new to mbed, and not particularly good at C/C++, and my mbed freezes after a while while continuously requesting acceleration measurements from a 6axis accel+gyroscope (MPU6050) connected in I2C. I am using Szymon Gaertig's library (http://mbed.org/users/garfieldsg/code/MPU6050/) ported from arduino I think, to link the 2 components.

I assume this is a memory problem, because i really have a hard time understanding the memory allocation process in c++, but I really do not know. I have run a few test to show the whole mbed is frozen (eg another thread with rtos making a led blink, the blinking stops when the main loop freezes too.)

My idea was first : To use global variables to stock my data :

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

DigitalOut myled(LED1);
Serial pc1(USBTX, USBRX);
MPU6050 mpu(0x69);
int16_t ax, ay, az;
int16_t gx, gy, gz;
int moyZ=0;                 //global Z value (mean)
int16_t moy[64];            //array of different measurements


void moyennage_Z()              //calculates the mean value by going through the whole array, sum and divide by the sample size (64)
{
    for (int n=0; n<64; n++) {
        moyZ=moyZ+moy[n];
    }
    moyZ=(int)moyZ/64;
}

void mon_thr(void const *args)      //blinking thread to test mbed's state
{
    while (true) {
        myled=!myled;
        wait(0.5);
    }
}

int main()

{
    Thread thread(mon_thr);
    pc1.printf("MPU6050 test\n\n\r");               //procedure to test the connection to the mpu6050, if valid
    pc1.printf("MPU6050 initialize \n\r");          //the code to execute is embedded in a if{}
    mpu.initialize();
    pc1.printf("MPU6050 testConnection \n\r");
    bool mpu6050TestResult = mpu.testConnection();
    if(mpu6050TestResult) {
        pc1.printf("MPU6050 test passed \n\r");

        while(1) {                                             
            for (int n=0; n<64; n++) {                          //refreshing the 64-int16 array
                mpu.getMotion6(&ax, &ay, &az, &gx, &gy, &gz);
                moy[n]=az;
                wait(0.01);
            }
            moyennage_Z();                                      //calculating the mean value by a simple sum and divide
            printf("%i\n\r",moyZ+17000);
            wait(0.1);
        }
    } else {
        pc1.printf("MPU6050 test failed \n\r");
    }
}

Then I tried to do in with malloc and free to be sure that the mbed did not reallocate a new space each time i used the mpu.getMotion6...

Same problem, after a while (a longer time though), everything freezes...

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

DigitalOut myled(LED1);
Serial pc(USBTX, USBRX);
MPU6050 mpu(0x69);
int *p;

int main()
{
    mpu.initialize();


    while(1) {

        p=(int*)malloc(sizeof(int));
        *p=(int)mpu.getAccelerationZ();
        pc.printf("%i\n\r",*p);
        free (p);
        wait(0.01);

    }

}

Please tell me if what i am doing is totally absurd or not, if this is an obvious memory issue or something more subtle/not concerning memory at all (maybe the I2C?). I know the first program is really not optimal concerning computing time and memory space, but i have to use all the other accel values and so in the end.

Thank you,

Aloïs

Hey, I cant see a memory issue in either of your examples, your not using any memory that you don't allocate, and your reusing that on each sample, I think its likely to be an issue in the library. How long are your i2c signal lines?

posted by Chris Pepper 18 Feb 2013

Also can you test without using the rtos library (remove it completely), its a complicated piece of code standing between you and the hardware that could be the issue.

posted by Chris Pepper 18 Feb 2013

At first I was not using rtos, and it froze anyway. I just wanted to see if the mbed was completely freezing or if it dropped the loop for some reason. It seems that with the rtos lib and 2 threads it stops after 15 cycles (15*64 measurements), and after 17cycles with rtos being completely removed...

As for the I2C signal lines I do not really know what you mean, I imported the library without giving much thought about it, I will try to tackle that issue.

posted by Aloïs Wolff 18 Feb 2013

I just meant the wires connecting the mbed to the MPU6050, I doubt that's the issue but a noisey/loose long connection might have a chance of crashing the library

Your code Isn't very different from the example one given with the library, so I don't think the problem is in your code

posted by Chris Pepper 18 Feb 2013

(By the way thank you for your help! :) ) the I2C lines are less than 10cm long (small wires), with 2.2kOhm pull-up resistors. Seems OK to me, but maybe it is indeed too long? As for the MPU6050 library, it is supposedly in beta, but I have no idea to what extent.

posted by Aloïs Wolff 18 Feb 2013

no that sounds fine, The only suggestion I have left is to print debug messages along the entire call chain even in the lib to find out when it crashes, then maybe we'l have some more idea about what's going on

posted by Chris Pepper 18 Feb 2013

Did that, it stops after 1120 i2c receptions just before calling (line 1901 of MPU6050.cpp) :

i2Cdev.readBytes(devAddr, MPU6050_RA_ACCEL_XOUT_H, 14, buffer);

it could be the accel that goes to sleep maybe... But i am quite clueless...

posted by Aloïs Wolff 18 Feb 2013

2 Answers

8 years ago.

In I2Cdev::readBytes there's a malloc I don't see a free for it. I think that could be it.

Accepted Answer

Wow! Thank you so much! I did not know why I assumed I2Cdev was a stable lib and it did not need checking.

added a free, everything works fine, you saved the (my?) day!

posted by Aloïs Wolff 18 Feb 2013

no problem =), make sure you report it to Szymon Gaertig its a fatal bug for his library.

posted by Chris Pepper 18 Feb 2013
8 years ago.

I guess (really, only guessing), that it could be the size of your buffer.
Try oversizing it a lot!!
This has helped me multiple times.

Lerche

you mean the int16_t[64]? Tried to increase it to 128, did not change anything...

posted by Aloïs Wolff 18 Feb 2013