Hey guys,

So right now I've got a project where I'm reading data from an accelerometer (MPU-6050) and then writing the data out on the UART to a bluetooth chip (RN-41). I'm facing a strange problem where it seems like sometimes, when the bluetooth chip is turned on, the microcontroller loop suddenly stops. I am writing the data values to a LCD as well, just to track whats happening, and these values stop updating. I think it has something to do with the bluetooth chip because when I do the same thing, and never turn the bluetooth chip on, or i disconnect it and just have it go to the USB port, the loop continues fine.

The problem is actually intermittent. Sometimes when the bluetooth chip comes on, everything is ok. Other times, it's ok when the bluetooth chip turns on, but then stops when the bluetooth connects to an external device.

It appears that theres something that is stopping my microcontroller in its tracks, but I'm not sure what. I was thinking maybe something dealing with the initialization between the microcontroller and bluetooth chip, but they are actually only connected by the serial data lines Tx and Rx. Does anyone have any ideas? I can post some code later on too.

0404,

Perhaps your TWI bus is getting hung up. I had a MPU-6050 running in a very noisy environment and, although it would often run successfully for hours at a time, occasionally the 6050 would hold a line low on me and freeze the code. I'm running a MPU6000 now using SPI - it's not only faster but doesn't hang. An alternative to going the SPI route is to try a hard reset and re-init of the MPU-6050 if there is some sort of hang up. Of course, I don't really know how this would correlate to your use of a blue tooth chip, so your problem may have nothing to do with the TWI at all but the intermittent nature of your symptoms sounds a little familiar.

Eric

Hi unnamed0404 -

Looked at the datasheet for the RN-41 and a couple of things stood out. First, it looks like a pretty awesome device...much more capable than the HC-6 and HC-5 modules I've been using (100m range is awesome). Second, you said you are only connecting Tx and Rx, which leaves out a common ground line and that could be a problem. It also says you should be on the same 3.3v Vcc rail too and CTS pin should be hardwired to the RTS pin but I'm not sure that would cause a problem. One thing I did notice was the factory set Tx power can go as high as 100mA which might be enough to brown out the MCU and reset it each time. I've had that happen several times on different projects. You might need a larger cap across your Vcc/Ground rails. Worst case you may have to opto-isolate the MCU but I can't see that being the case since it is designed for MCU integration. If you have a scope you could test the power rail for dips. If not, code in a blinking LED at the beginning of the program cycle (have it last a few seconds only) to see if you are getting a reset. Other than that we might have to see the code.

Hi Eric, pcbolt,

Thanks for the prompt responses.

To Eric: Yes, I was thinking about the accelerometer chip hanging as well, however it seems it only happens when I have the bluetooth chip hooked up and on. I hooked up an oscilloscope to the SCL line, and it seems kind of inconsistent. Sometimes when it stops, the SCL line is pulled low, implying clock stretching by the MPU-6050 maybe. But other times when it stops, SCL line is still high. Does this mean anything? Is there another way to tell that the MPU-6050 is the one hanging?

To pcbolt: Yes, I was thinking about the current draw of the bluetooth chip as well, but it seems kind of strange because it usually happens before the bluetooth chip connects to the external device. In my experimentation, it seems like there are no problems if the bluetooth chip connects to the remote device right away. It is also in this mode that I think the most current is being drawn by the device (while it is transmitting). However, if the bluetooth chip never connects to a remote device, meaning it just stays in its "searching" mode, usually eventually the loop stops. (but not always). I like the idea of adding more capacitance between the vdd and gnd rails, as that beginning transient current pull may be causing fluctuations in vdd. I tried doubling, and quadrupling the cap I had in there, which was 100nF, 200nF, 400nF, but the problem still occurs. Should I increase the cap even more?

I think I would try to determine if a resetting of the MCU was the problem before trying more caps. To diagnose the problem I would code in the LED indicator sequence first, just to see if the MCU was getting reset each time. This is as simple as;

DDRC |= 1<<PC1;   // PC1 to LED to 1k resistor to ground
PORTC |= 1<<PC1;  // Turn on LED - optional
uint8_t test_led = 5;
while(1){
    if(test_led--){  // this should last about 1 second
        PORTC ^= 1<<PC1;   // toggle LED
        delay_ms(200);
    }  // after test_led = 0 this code will not execute again
    /// existing code here
}

Next step would be to look at the code you're using - unless you haven't tied the MCU and RN-41 grounds together, but I'm guessing you did that.

PS -

I've found loose wires in the breadboard giving me a "false" resets that aggrivated me to no end too :-)

CORRECTION

The code I posted above won't work right.

if(test_led--){  // this should last about 1 second
    PORTC ^= 1<<PC1;   // toggle LED
    delay_ms(200);
}  // after test_led = 0 this code will not execute again

That code will execute more than once so it should be replaced with...

if(test_led > 0){  // this should last about 1 second
    PORTC ^= 1<<PC1;   // toggle LED
    delay_ms(200);
    test_led--;
}  // after test_led = 0 this code will not execute again

thanks for the suggestions! I've been very busy at work the last couple of days, but I will give this a try tomorrow