(Studio Ver 7.0.2397, ATMega1284p, Atmel-ICE)
In the course of debugging an issue which 'appears' to be an issue that causes the code to return on a destroyed stack (i.e.: execution goes to a totally unexpected code location) my Atmel-ICE or debugger exhibits this behavior:
* I place a single breakpoint at a location that is being executed unexpectedly (note: this module was compiled with -O0)
* command "Start Execution and break"
* artificial break at 'main' is hit
* command: Run
* the breakpoint is hit correctly during initialization
* command: Run
* application resumes normally (as indicated by serial port trace info and target board LED activity)
* command: 'break all'
* execution stops at a random (correct) location
* command: Reset (to simulate a reset button press)
* artificial break at 'main' is hit (Init1-5 assumed to have executed but I do not have a breakpoint set there)
* serial port tracing indicates that the application starts normally and the breakpoint is again hit normally during initialization ...
* But then the code (where the breakpoint is) is again executed unexpectedly (as indicated by serial port tracing) BUT the breakpoint is NOT hit.
* If I hit 'break all' to pause execution, Atmel Studio says "The application is in break mode'.
* No more Studio commands are effective at this point.
This seems to indicate that, when the program bug occurred (again, assumed return on destroyed stack), something happened to cause the Atmel-ICE to loose control of the debugging session.
As I understand it, when a small number of breakpoints are set (i have two, my breakpoint and the temporary "Start Execution and break" breakpoint) the ATMega1284 stores these in a special break register set and does not modify code as it does with a large number of breakpoints.
(BTW: there is no bootloader code in memory that could modify flash space.)
What could my code have done to cause the Atmel-ICE to lose control of the target?