2025-03-28 5:11 AM
Is there a way to have this breakpoint only enabled at the start of the debug session?
So, when the code is first loaded, it will stop at main(); but then after subsequent resets I set my own breakpoint.
It doesn't appear in the list of breakpoints, so I can't clear/disable it from there.
Solved! Go to Solution.
2025-03-30 5:49 PM
Uncheck "set breakpoint at main". Then in the editor set a breakpoint on main and change its type to temporary (in Breakpoint properties). Then start debugging. The program will still break once at the reset handler, resume automatically then break on main. Next resets won't break at main or reset handler.
2025-03-28 7:20 AM
I don't think so.
You can set "conditional" breakpoints in code which may achieve a similar result. Check if the debugger is connected, then check whatever flags you want (maybe a flag in RCC->CSR), and execute __BKPT();.
2025-03-30 5:49 PM
Uncheck "set breakpoint at main". Then in the editor set a breakpoint on main and change its type to temporary (in Breakpoint properties). Then start debugging. The program will still break once at the reset handler, resume automatically then break on main. Next resets won't break at main or reset handler.
2025-03-31 6:41 AM
Thanks - that seems useful.
So what, exactly, is a "temporary" breakpoint?
It seems that it's applied only once in a debug session, but is retained between debug sessions.
Help is no help:
2025-03-31 8:39 AM - edited 2025-03-31 8:44 AM
A temporary breakpoint is a breakpoint automatically removed after stopping on it.
It seems that Eclipse has two "modes" of displaying breakpoints. In the editor perspective you can set breakpoints and assign their properties. The Breakpoints view will show all the breakpoints in source files of the project.
When debugger starts, the Breakpoints view of Debug perspective shows the runtime state of the breakpoints. I'm not sure about internals, looks like it starts from the initial breakpoint specified in the debug settings. If none is specified it breaks on the reset handler. When stopped at this initial breakpoint, it tries to set the breakpoints from the project files. If the "resume" is checked, it then automatically runs.
After this, temporary breakpoints are automatically removed from the Breakpoints view, even though you can still see them in the editor. Eclipse is complicated ((
2025-03-31 8:55 AM
@Pavel A. wrote:A temporary breakpoint is a breakpoint automatically removed after stopping on it.
So "removed" from the list of breakpoints during the debug session, but will be remembered between debug sessions.
Maybe this is why they don't document it - they can't think of a way to describe it!
2025-03-31 1:05 PM - edited 2025-03-31 1:11 PM
Interesting and undocumented behavior occurs on target reset.
From my observations, the default ST debugger ("GDB server") always intercepts the reset event. Then it will add a temporary breakpoint on main or other address, if the checkbox "breakpoint at " is checked. Then it will resume automatically (unless the Resume checkbox is cleared). Otherwise, the ST debugger does not interfere with the reset.
So: if the checkbox "breakpoint at main" is NOT checked, but instead you set a temporary breakpoint at main in the editor: this breakpoint will occur only once in debug session. Following target resets (for any reason) won't break at main again because it was a temporary breakpoint.
The IAR debugger behaves differently. When it takes the target reset event, and the start address is "default", it will follow the vector table of the loaded program. The effect is that, if there's a "bootloader" and you debug the "main app", the debugger will always jump directly to the main app, bypassing the bootloader. To always execute the bootloader, have to specify its start address rather than leave "default".
With ITM, things are more complicated. It still is not clear to me when the debugger connects to the ITM and what happens on resets or change of core clock.