I'm fairly sure that I'm into a stack overflow/buffer overrun bug in my (FreeRTOS based) application on an ATMega32A. It gets through initialization and initial task creation but very shortly after that it re-executes the "main" function (as shown by a breakpoint). My guess is that this is most likely due to executing a 'return' through a clobbered stack frame/marker. I think I need to understand WinAVR frames better to track this down - besides, I should know it anyway ... Can someone suggest a good web site/doc where I can read about the stack frames/markers produced by WinAVR (GCC)? At the moment, I'm trying to 'sneak up on it' with breakpoints, UART traces, disabling sections of code, disabling interrupt handlers, etc. FreeRTOS has some stack overflow detection logic (which I have turned on) but, AFAIK, it is only invoked on task switches. Another question: Is there a way to have WinAVR emit a macro/function invocation on function entry and exit? This would help 'instrument' the code with verification logic. I know I can insert my own but I wondered if there was a WinAVR supported way to do this quickly and thoroughly. A "stack trace back" would be nice but it's not available in AVRStudio. I have not yet gotten up the GDB (which I believe does have a stack trace back) interface in the Code::Blocks IDE yet (maybe my time would be well spent on that ...). Other than that, and suggestions on tracking this down would be welcome. General Pondering: Stack overflow can be a difficult problem because, particularly in embedded systems, it is dependent on the 'worst case' stack depth which is subject to interrupt timing, etc. I wonder why processor manufacturers have not added a hardware "Stack Fence", such that, if the stack grows past this a trap occurs. Sure would be nice for me at the moment and, I suspect, would catch some product malfunctions in the field. Cheers, Chuck Hackett "Good judgment comes from experience, experience comes from bad judgment" 7.5" gauge Union Pacific Northern (4-8-4) 844 http://www.whitetrout.net/Chuck
Message
Understanding, trapping and debugging stack overflow on an AVR
2011-01-11 by Chuck Hackett
Attachments
- No local attachments were found for this message.