0

I am writing a simple baremetal code for STM32. I wrote the linker and the startup code similar to this . My understanding is that the .text section will be placed in the flash memory of the controller.

Question:

In such a case, it is not possible to use software breakpoints right? From what I've read sw bp replace in memory the optocode with the break optcode (and keep the real optocode in some table, etc. ) in order to halt the processor. This cannot be done on non-writable memories like flash, where my code is, and hence where the program counter points to.

C Marius
  • 229
  • 1
  • 6
  • Keep in mind the on chip debug adapter gives you a few hardware breakpoints, which is enough if used strategically. Debugging is strategy more than tools. – Chris Stratton Jun 13 '20 at 12:53

1 Answers1

1

Your understanding of software breakpoints is basically correct: the code is modified, i.e. a breakpoint instruction is inserted in place of the real instruction and the real instruction is saved somewhere else. The specific technique depends on the debugger, CPU and operating system.

Few debuggers are capable of applying software breakpoints in MCUs with the code residing in flash memory. But since flash memory can be changed (after all you upload your code to it), sophisticated debuggers can still use them.

One of them is SEGGER's J-Link (at least certain versions). See their Unlimited Flash Breakpoints feature for more information. They don't give away all the details of the implementation though.

So with the right debugger, you can still use software breakpoints in your bare metal project.

Codo
  • 2,038
  • 8
  • 14
  • 1
    Such sophisticated/advanced debuggers manage this, but I guess they worn-out the flash quicker ... in some areas where the breakpoint is set. Right? – C Marius Jun 13 '20 at 10:49
  • I've never heard that this is a problem is practice. – Codo Jun 13 '20 at 18:43