If you just kit the stop/pause button, it will stop where ever it happens to be. I think it may have been you who had a previous ticket on setting the pc to some value, which I think is a very bad idea because interrupting the normal flow of code can cause memory issues. So a lot depends on how you got there, used the debugger to change any variable values, paused the application long enough for tcp sockets to time out, etc. Stepping through code or pausing code on a system that interacts with outside connections that can request retransmissions or timeouts can create issues that would not be there otherwise.
I am seeing the exact same issue as the original poster, after simply starting my SB72-based application under the debugger. No breakpoints are enabled, I have not tried changing any variables or registers, just running the code. If I hit "Go", the code will run for a short while and then stop at the same location again. It's like there's a breakpoint set in this code, even though I have verified that all breakpoints are deleted. Any ideas?
I see this if there is any crash in one of the tasks I have running. It makes tracking it down a little harder.
What I do is look at the debug window where the list of tasks if located (normally top left) and check each one in turn to see where it has paused. Generally the task with the corruption is the one that is no in OSSched. This has been the case for me until recently when I am still trying to track down an elusive memory bug.