I'm currently playing around with an MPU-9150 / Quaternion math and such and after a few minutes of running the controller stops sending anything to the Serial port (console). I have converted an ARM application written by Kris Winer (MPU-9150 AHRS to work on the Mega 2560 and it seems to work OK except for this hang.
The length of time it runs varies but it always hangs eventually - or does it - is this simply a Serial port issue? (although I did set up an LED to flash on code execution and it stops flashing so I assume this is a hang)
I do have many applications that will run for days on the same board for what it is worth so this isn't hardware I don't think ...
So - how do I trap 'fatal' or other processor / board issues to prevent this hang - to fail gracefully and report the issue instead of just dying.
And if you can't how the **** am I supposed to figure out what is going on ??
PPS : The code triggers a compiler error (: multiple definition of) but it shouldn't.
MPU9150.h (9.13 KB)
MPU9150.cpp (27.3 KB)
I have run through such problems in my career many times and the reasons range from going over the RAM usage coupled with/due to variable overflow etc(which for the mathcomputations can happen bcz the ATmega2560 isn't having any sophisticated math crunching engine on it for e.g. KL25z ARm uC has a floating point crunching engine in it so maybe many of the floats and doubles in the quaternion math can add up to heap saturation, again not knowing too detailed things this may be a possibility)
or its a compiler error, there are programming amalgamates that are not raised by compiler (eventually the truth is that compiler cannot ascertain almost every other human logic error) but these errors internally halt the programme, try checking your logic and other errors not possibly compiler errors or compiler warning's that let you build the code successfully but not deny the software being loaded to the chip.
I don't suppose there are any libraries / calls that you are aware of that will permit some kind of detection of overflow conditions / heap usage etc etc
I don't suppose there are any libraries / calls that you are aware of that will permit some kind of detection of overflow conditions / heap usage etc etc
There is! one and I use it, have used that library on ATmega328p chip.
Its called memoryFree, you can use their code source to read the ram consumed and it should help you.
Well done a lot of digging and it would appear that the guilty party is the wire library - and it seems that I'm not alone experiencing issues with I2C behaviour with it.
I've no clue how to fix this since the device I need to use is I2C - but I can't tolerate a sketch hang with what I'm doing.
Looks like the MPU9150 is a good idea but damn hard to implement in a reliable and robust way when other 'communication' mechanisms are also present. Even disconnecting the power to the MPU9150 can hang the sketch.
Well done a lot of digging and it would appear that the guilty party is the wire library - and it seems that I'm not alone experiencing issues with I2C behaviour with it.
I think I get it ,happened with me too, this happens at times when the wiring is floating on the i2c connections check the connections and make them good,also are your i2c pullups good enough? 4.7k or 10k?
The pullups are supposed to be 10k Schematic
I've tried all sorts but short of directly soldering everything there's not much opportunity for improvement.
I have 15cm patch cables board to board and still it is unstable - I've tried it on both a Mega2560 and a DUE now - the results are the same, it is unstable / unreliable, sometimes it will work for an hour sometimes it bombs on initialisation.
BenKenobi:
The pullups are supposed to be 10k Schematic
I've tried all sorts but short of directly soldering everything there's not much opportunity for improvement.
I have 15cm patch cables board to board and still it is unstable - I've tried it on both a Mega2560 and a DUE now - the results are the same, it is unstable / unreliable, sometimes it will work for an hour sometimes it bombs on initialisation.
Try 4.7K pull-up resistors. The pull-up requirements are not cast in stone... the longer the length of the connection, the 'stronger' the pull-up requirement.
Pull-up calculations
Ray
Will do, just as a sub note I think I'm getting closer - it seems that timer interrupts are not mutually exclusive - i.e. one executing doesn't prevent another on a different timer from firing and this seems to cause some bother.
If I have everything inline i.e. just executed within 'loop' things mostly work and never hang if I put a 'flag' in the interrupt handlers i.e.
ISR(TIMER2_COMPA_vect)
{
if(!bTmrIntActive){
bTmrIntActive = true;
sBus.process();
bTmrIntActive = false;
}
}
ISR(TIMER3_COMPA_vect)
{
if(!bTmrIntActive){
bTmrIntActive = true;
gps.process();
bTmrIntActive = false;
}
}
ISR(TIMER4_COMPA_vect)
{
if(!bTmrIntActive){
bTmrIntActive = true;
mpu.process();
bTmrIntActive = false;
}
}
then things seem to behave a whole lot better and don't hang nearly as quickly or as often. With the code inline though it never hangs - problem then is that the registers I'm reading frequently contain rubbish.
Weaker resistors may help keep the MPU under control better.