I worked on this a while back and the rule that I required
OpenOCD to follow was that it should *always* be possible
to write startup sequence that could debug the board,
regardless of whether the previous debug session crashed
(OpenOCD or GDB), state of target, etc.
So any dangling breakpoints mu
duane> Slowly target resources are consumed/leaked - specifically hardware
duane> compare registers.
duane> Suggestions?
BTW - this can also be caused by GDB croaking.. while leaving the target
running.
Examples - SVN 2408 - adds some useful debug information to help see
this problem
The g
The cortexM3 - and perhaps other targets - have a problem.
When GDB exits/disconnects/reconnects - these two functions get called:
/* we must remove all breakpoints registered to the target as a previous
* GDB session could leave dangling breakpoints if e.g. communication
* timed ou
