1

When I'm following this procedure, program execution is successfully stopped when the payload program is run:

  1. Setting breakpoint to beginning of program which is gets loaded by the bootloader afterwards. The breakpoint gets set with the GDB command break *0x2000001c. As OpenOCD tells me that the CPU has 6 harware breakpoints when connecting, I suppose one of those is used.
  2. Resetting Mikrocontroller with GDB command monitor reset run
  3. Loading programm by bootloader into the SRAM region.
  4. Halting and then continuing execution by GDB commands monitor halt and continue.
  5. Instructing bootloader to run loaded program.

However, when I'm exchanging step 3. and 4, program execution is not stopped when hitting the breakpoint.

Can anyone tell me why? It seems to my, that the core "looses" the breakpoint when the register the breakpoint is set to gets overwritten.

This is the equipment I'm using:

  • STM32F4 mikrocontroller
  • ST-Link
  • OpenOCD
  • GDB
Multisync
  • 215
  • 1
  • 2
  • 7
  • 1
    Is this a hardware breakpoint or a software one? On code or on data? In RAM or in Flash? You may be expecting a lot to have a breakpoint survive a code change on this type of system, as debug hardware may be reconfigured and instruction-replacement soft breakpounts overwriiten - survival could depend on the debugger remembering to re-implement them afterwards. – Chris Stratton Feb 10 '15 at 19:22
  • @ChrisStratton: Thanks for your advice! I wasn't aware that these things are influencing debug operation. Please find the additional details you asked for in my original question. – Multisync Feb 10 '15 at 19:30
  • Have you attempted to use the hbreak instruction to create the breakpoint. You might actually be using software breakpoints. This may then overwrite the breakpoint on the load. Even then, the load may clear hw breakpoints. – caveman Feb 10 '15 at 19:33
  • 1
    Also if you type info break just after loading, are the breakpoints still there? – caveman Feb 10 '15 at 19:35
  • @caveman: Yes, they are! I will check if `hbreak` works at the next opportunity. – Multisync Feb 10 '15 at 19:37
  • @caveman: Unfortunately the behaviour when using `hbreak` was the same as when using `break`. – Multisync Feb 12 '15 at 18:56

1 Answers1

1

The fact that exchanging steps 3 and 4 doesn't work (doesn't break the program) suggests that operation 3 has the effect of clearing the hardware breakpoints, and that a "trivial" interaction between the debugger and the program has the effect of re-installing the breakpoints.

If in your environment you don't have a way to load the program in a halted state, and then install breakpoints and start it, and if you need this in order to debug something which happens unconditionally, early in the execution, you might be able to insert some kind of software breakpoint into the program, in code which executes even earlier than the situation you're trying to debug.

Kaz
  • 19,838
  • 1
  • 39
  • 82
  • I suppose you mean to actually write a breakpoint into the source code of my program, rather than instructing the debugger to patch the program image to execute? Can you elaborate (or perhaps provide an link) on how this is usually done? Right now, the only way I can think of is to insert a while-loop whose condition is a `volatile` variable. To continue execution, I would have to change the value of that variable in a way that the condition is no longer evaluated to `TRUE`. Are there other, more elegant ways? – Multisync Feb 12 '15 at 19:03