I would like to add to this list the possibility of a stack/heap collision if dynamic allocation is being used. I am not sure on the specifics of the project at hand [I will not ask either], but if the timer interrupt "stops working" that essentially means something turned off the interrupt somewhere/the timer configuration got changed. I would try to use the WDT to reset the device and dump the timer registers upon power on to see what happened.
On Mon, 2013-07-29 at 21:25 +0000, Grant Edwards wrote: > On 2013-07-29, ravim <ravi.mandl...@gmail.com> wrote: > > > I will try to do what you have suggested. Issue is we fear that so > > much is happening in our code too fast (flash write, blacklist check, > > then communication with different devices etc), we fear we might be > > corrupting stack somehow with so many global and local variables. > > That doesn't really make much sense. It doesn't matter how many > things you do or how fast you do them. > > Things that will cause intermitten failure after running for a while: > > * stack overflow (or underflow) > > * dereferencing uninitialized pointers > > * buffer overflow (or underflow) > > * race conditions > > To check for stack overflow, the the easiest thing to do is to > initialize your stack space with a recognizable pattern. You can then > periodically check to see how much of the stack still contains that > initial pattern. If you can stop program execution when it fails, you > can check the stack space to make sure that some of it still contains > the initialization pattern. > > > Is there any way through which we can figure out what is actually > > happening (read the stack etc), why things go smooth for an hour or > > so. If we change sampling window, timing varies but eventually, it > > will stop. > > If it's not stack overflow, then my _guess_ is that you probably have > a race condition between forground and interrupt, between two > interrupts (if you allow interrupts to nest), or between two threads > (if you've got a multi-threaded system). >
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
