--- In AVR-Chat@yahoogroups.com, "Chuck Hackett" <egroupscdh@...> wrote: >[...] but very shortly after that it re-executes the "main" >function (as shown by a breakpoint). That sounds like it could be data corruption due to the stack colliding with statically allocated data. It could, however, be an interrupt for which you have defined no handler. > I think I need to understand WinAVR frames better > to track this down - besides, I should know it anyway ... The avr-libc documentation (installed with WinAVR in the 'doc' directory) contains a brief description of how parameters are passed to functions. When possible, the parameters are all passed in registers so the stack frame consists only of the return address. If you have too many parameters to be passed in registers only, some of them are pushed on the stack. The stack is also used for calling variadic functions. If a function allocates local storage that is too large to be held in registers, space is created on the stack for the extra variables. These variables are references by an offset from the Y register. Since r29:28 are among the "call preserved" registers, the previous content of r29:28 are pushed on the stack, too. You can best understand how all of this works by looking at the .lss file to see what code is generated in different circumstances. Some simple test cases will allow you to create different scenarios. > Other than that, and suggestions on tracking this > down would be welcome. It is often useful to capture the "reset flags" (typically in the MCUCR register but check your datasheet) and then clear them. This register has bits for each reset cause. If you get back to main() and no reset flags are set then you know that you got there by a means other than a reset. You can set a breakpoint on the "catch all" ISR to detect when that is the cause of restarting. You can "seed" the stack area with a known value and then inspect it at various times to detect when the stack is all "used up". This will be more complicated in a multi-tasking environment because you undoubtedly have multiple stacks. Don Kinzer ZBasic Microcontrollers http://www.zbasic.net
Message
Re: Understanding, trapping and debugging stack overflow on an AVR
2011-01-11 by Don Kinzer
Attachments
- No local attachments were found for this message.