I’m working on a project using an LPC1768 running at 100MHz interfaced to various sensors and an LCD for output. I’ve completed development of the code and have been running the hardware for days at a time to root out any issues that only appear after running for long periods (e.g. memory fragmentation, stack underflow, etc.) I start the code running on the board under the Rowley CrossWorks debugger so I can periodically break into the debugger to examine data structures, set breakpoints, single step the code, etc.
When I do this, everything runs fine for a day or so, and then the debugger seems to loose its ability to single step code and stop at breakpoints. Most other debugger functionality continues to work normally: I can examine memory and registers, look at data structures, etc. If I set in breakpoints in code that’s known to execute (based on hardware behavior), they are never taken, although the processor continues to execute code in the sections where breakpoints have been set.
A similar thing happens when I try to single-step the code. Invoking any of the single step commands (Step Into, Step Over, Run to Cursor) cause the processor to start free running from that point rather than stepping one C statement (or one assembly instruction in Disassembly mode).
This behavior is consistently reproducible: simply run the board under the debugger for more than 1-2 days and it will sooner or later loose the ability to stop at breakpoints or single step code. Needless to say, this is impacting my ability to debug issues that only occur after the system has been running for long periods.
Has anyone seen this behavior? Any idea of what may be happening or workarounds to fix the problem? I’ve reported this to Rowley tech support, but haven’t received a response yet.
Software: Windows XP SP3, Rowley CrossWorks for ARM 2.0.5
Hardware: LPC1768 @ 100 MHz, Segger J-Link