Hi,
Sorry, we are not aware of this issue, however we can suggest a possible explanation and a workaround.
The behavior you described could happen if gdb set software breakpoints in some locations in RAM (i.e. placed the ‘breakpoint’ instruction in specific locations in RAM) and then some of the code would overwrite these instructions (e.g. re-initialize RAM from FLASH again).
If this is the case, please consider setting a hardware breakpoint somewhere in the FLASH memory after the RAM got initialized. Hardware breakpoints will not be affected by RAM overwriting, and once the breakpoint is triggered, gdb will automatically re-insert the RAM breakpoints, repairing the ones that got broken.
If it doesn’t help, please share more details about your setup:
- How exactly do you restart the program?
- What debug tool (e.g. OpenOCD/J-Link Software) you are using?
- Are the broken breakpoints set in FLASH or RAM?
- Does using the “hbreak” command to force gdb to set a hardware breakpoint change anything?