[Feature Request]: Improve support for breakpoints for code loaded into RAM for execution

[jreineckearm]

Description

Problem

I have an application that is stored in flash memory. Parts of the application code are copied to RAM (e.g. TCMs) for execution. This happens while booting the application, e.g. as part of scatterloading.

When a debugger connects, it sets a temporary breakpoint at main before starting the execution. However, if this breakpoint is installed as a "SW breakpoint" (i.e. by replacing code with a BKPT instruction), then the boot/scatterload process will overwrite the memory with the application code and effectively erase the breakpoint.

Using HW breakpoints instead would solve the problem. But would also remove the big advantage of SW breakpoints. Which is that they are normally not limited in number (compared to HW breakpoints).

Some other information

• GDB gets hints of where to use HW and SW breakpoints in the form of memory maps with RO and RW regions. But RAM is normally marked as RW.
• *.cbuild-run.yml files have memory descriptions which allow to specify RO/RW regions.
• GDB has commands to explicitly set HW breakpoints instead of SW breakpoints.
• pyOCD seems to have a command line option -bh which always forces HW breakpoints. Such configuration may however not be available on other GDB servers.
• Other debuggers like uVision have commands to explicitly suppress usage of SW breaks for memory regions.

Questions

• What's the best way to deal with the above problem?
  • Make use of global switches to turn SW breakpoints on/off? Does this scale over different GDB servers? Would be SW breakpoints then useful in real world scenarios (where a bootloader copies code over after each reset)?
  • Refine pyOCD breakpoint strategy to make cleverer use of the available resources, e.g. if not explicitly specified, use HW breakpoints until they are exhausted, and only then start using a mix of SW and HW breakpoints.
  • Extend *.cbuild-run.yml debugger settings with something to specify regions where SW breaks are prohibited (like uVision SBC command)?

This needs a little more thinking, hence the above options to consider.

Simplest workaround

The simplest workaround for such scenarios would be to replace the current tbreak main init/customReset command with thbreak main. But this doesn't help with other randomly set breakpoints.

Is this request a Security Requirement?

• Yes

Priority

Medium

Related Issues (Optional)

No response

Additional Notes (Optional)

No response