Breakpoints Stop Working
I have the latest version of CrossWorks for ARM and use it with a Segger JLINK with a LPC4357 and an LPC1768 development board. Right after loading the code to the board, I can start the application running and while it's running, if I click in the margin of a line of code, a breakpoint gets set and execution stops when it hits that breakpoint.
If I leave the application running for a day or two (it's an embedded application that will be running 24/7 when I finish the project), if I click in the margin to set a breakpoint, the breakpoint appears to be set (the red dot appears). The breakpoint is never taken, however, and the processor never stops even though I know it executes the code containing the breakpoint.
This behavior is consistent: if I leave the application running, it will always get into a state where breakpoints no longer seem to be recognized.
When it gets into this state, the pause button will stop the code.
Is this a known issue and is there a fix?
-
Hi Jerry,
I've seen this sometimes, don't know if it is the same thing however. Sometimes, it seems that the debugger has been disconnected from the target board. Usually there is a message, but sometimes I think it gets missed. The application is still running, but setting breakpoints is irrelevant at that point. You might try one of two things: 1) "Attach" the debugger to the project again if you can and/or 2) Hit "pause" on the debugger and see where it stops (if it does).
Again, might not be the same thing, and maybe the Rowley guys have better / different answer...
Matt
-
I've been using CW2.3 (Windows 8.1) for a while and had not seen this. But recently I updated to CW3.6.2.2015120115.26456 (Windows 10) and I see this all the time.
Using STM32F4 with STLink V2.
[1] Lay three or so breakpoints (init routines for example).
[2] Program flow halts on breakpoints, keep resuming until program flow reaches a point where no breakpoints fire.
[3] Add an additional break-point where it is guaranteed to hit (like an inner-loop or common task)
[4] CW does not halt[not ok]
[5] Quickly Pause and resume debugger ( Break and Go), now the additional break-point lands [workaround].
-
I've been using CW2.3 (Windows 8.1) for a while and had not seen this. But recently I updated to CW3.6.2.2015120115.26456 (Windows 10) and I see this all the time.
Using STM32F4 with STLink V2.
[1] Lay three or so breakpoints (init routines for example).
[2] Program flow halts on breakpoints, keep resuming until program flow reaches a point where no breakpoints fire.
[3] Add an additional break-point where it is guaranteed to hit (like an inner-loop or common task)
[4] CW does not halt[not ok]
[5] Quickly Pause and resume debugger ( Break and Go), now the additional break-point lands. [workaround]
-
I can confirm the exact same results as Omar Zrien on Linux X64 version (Debian 8 Stable) using STM32F0, STM32F1 and STM32F3 and ST Link/V2.
If I place the Breakpoint when not executing it sets properly. If I set it while running it is sometimes seen but mostly not until I pause and resume again.
It seems to be a regression that started with 3.6.0 and is still present in 3.6.2. Setting while running always worked in all other versions I have used in the 2 and 3 series until 3.6.0. I have used most releases in between, but not all.
It has annoyed me since this started, but I have been too busy to post anything about it until now as I learned the same workaround in #5.
-
I'm seeing this as well in 3.6.2 for Mac. I'm using an ST/Link v2 with an STM32F405. Putting a breakpoint in certain parts of my code will prevent all breakpoints from working. I don't even have to trigger the breakpoint - I just have to set it in certain parts of my code. If I then set a breakpoint in, say, the main tick handler, the breakpoint no longer triggers. However, if I then do a manual break and continue, the breakpoints now function.
Please sign in to leave a comment.
Comments
10 comments