I've got an MSP430G2553 logging temperature sensor values to an SD card, and I've run into a problem. It seems that after about half a day of running (or just randomly), it just stops running the code it was working on. It still reacts fine to interrupts, but I've got no idea why it stops flashing the LED and recording values. If anyone wants to see the code then I can post it, but I'm hoping there's something stupid I've missed here that I can fix quickly.
In terms of power supply failure, I doubt that's it. It's got a 2200u cap right across the power, and it's being powered from a 3.3v linear regulator, with a 6v lead acid.
It can't be shutting down because its interrupts work okay, but it just completely stops running code.
Look for stack overflows and check every loop in the software.
Comment out certain sections of your code to narrow down the problem.
Also check null terminations on all your strings, these can easy trash your SD card as well as crashing your program.
and get the watchdog going.
Oh I forgot to mention, I'm using the stupid Energia IDE, which basically won't let me do any debugging (I think) so I pretty much can't do the things you've mentioned
Also, how do I check for null terminations?
Sorry about the lack of knowledge here, software isn't my strongest point unfortunately.
just comment out different sections of your code that might be the cause. For example the line that says filewrite(,,); or something similar.
any string you pass to a function which both
a) takes a (char *) or a (const char *)
b) doesn't have a length parameter
will need to have the null character at the end of it. null being the value 0.
otherwise the function will not know the correct length of the string, so the function will keep looking at each character until it finds null.
If you are writing to some other string, the writing wont stop until it finds the null and so you will have overwritten some important bit of memory, resulting in a crash.
http://www.exforsys.com/tutorials/c-language/handling-of-character-strings-in-c.html That might help.
Sorry about the lack of knowledge here, software isn't my strongest point unfortunately.
Make it strong.
I've got an MSP430G2553 logging temperature sensor values to an SD card, and I've run into a problem. It seems that after about half a day of running (or just randomly), it just stops running the code it was working on. It still reacts fine to interrupts, but I've got no idea why it stops flashing the LED and recording values. If anyone wants to see the code then I can post it, but I'm hoping there's something stupid I've missed here that I can fix quickly.
In terms of power supply failure, I doubt that's it. It's got a 2200u cap right across the power, and it's being powered from a 3.3v linear regulator, with a 6v lead acid.
It can't be shutting down because its interrupts work okay, but it just completely stops running code.
Bear in mind that those SD cards have little mcus in them too and they can take a while to process each request. If your code is doing a write every second, and the SD card takes longer than that to finish a previous request, your code may break. I ran into this problem on a data logger using FatFS on STM32.
In addition to checking for stack overflows and such in your own code, make sure you're checking return values from the filesystem and/or SD card driver. If you see "device not ready" or something similar, it probably means the SD card is busy.
Thanks very much, I'll get to work on that now!
Shame it's an error that takes so long to find, at least a day of testing for each line I comment out
And I'm trying to make it strong! Hopefully moving onto the Tiva C boards with Tivaware (real C) in the next week or so
I've got an MSP430G2553 logging temperature sensor values to an SD card, and I've run into a problem. It seems that after about half a day of running (or just randomly), it just stops running the code it was working on. It still reacts fine to interrupts, but I've got no idea why it stops flashing the LED and recording values. If anyone wants to see the code then I can post it, but I'm hoping there's something stupid I've missed here that I can fix quickly.
In terms of power supply failure, I doubt that's it. It's got a 2200u cap right across the power, and it's being powered from a 3.3v linear regulator, with a 6v lead acid.
It can't be shutting down because its interrupts work okay, but it just completely stops running code.
Bear in mind that those SD cards have little mcus in them too and they can take a while to process each request. If your code is doing a write every second, and the SD card takes longer than that to finish a previous request, your code may break. I ran into this problem on a data logger using FatFS on STM32.
In addition to checking for stack overflows and such in your own code, make sure you're checking return values from the filesystem and/or SD card driver. If you see "device not ready" or something similar, it probably means the SD card is busy.
I'm only writing every 15 minutes, so I doubt this would be a problem.
I'm thinking it could be something hardware, maybe it's getting bumped or the linear reg is doing something strange occasionally?
What's most likely though is I've screwed up my code somewhere, some of my variables may be going above the size of value they can handle, or I've just done something that's causing it to fail occasionally.
If you don't have debugging, you can always use print statements with a timestamp or increment number, when it stops you can narrow down to where and when this occurred
See if you can log the contents of all your variables every time you log the temp. This sounds like was said before an overflow or perhaps running out of memory.
Since your interrupts are still working you could consider using the Watchdog timer for its intended purpose (resetting the chip if it got stuck for whatever reason).
Letting the watchdog take care of these kind of problems isn't a solution. There is a problem which needs to be addressed.
How did you implement the delay and what version of Energia are you using? In E0009, milliseconds() was restarting at 0 after only a few hours, which might trip up your program. E0010 adjusted this behavior to a few days, making it compatible to Arduino.
Chicken, that could've been the exact problem! But unfortunately, no dice, I'm using E0010
Start a thread in the 43oh.com forum. The regulars there are usually quite helpful in tracking down these kind of issues.