hardware breakpoints on a STM32H7

[silentbuteo2]

I try to set a HW (data) breakpoint, but this fails with the error:

Failed to resume debugging. You may have requested too many hardware breakpoints. Please try disabling some of them and try resuming your session again.

Even if there is only 1 breakpoint.

manually setting seems to work

watch *0x30040e36
&”watch *0x30040e36\n”
Hardware watchpoint 4: *0x30040e36
=breakpoint-created,bkpt={number=”4″,type=”hw watchpoint”,disp=”keep”,enabled=”y”,what=”*0x30040e36″,thread-groups=[“i1″],times=”0″,original-location=”*0x30040e36”}
OK

Tried with both -O0 and -Og

[support]

Hi,

Please try double-checking the exact breakpoints set by gdb by running “info breakpoints”. You might have set additional breakpoints that are not shown in the regular Visual Studio GUI.

Also please note that stepping over/out of functions requires creating a temporary breakpoint, that counts toward the overall limit.

You can also obtain a full gdb log of the debug session as shown here and search for breakpoint-related command to understand what contributes to the breakpoint amount the most.

Please also consider using Segger J-Link instead of your current debug probe, since it supports seamless software breakpoints in the FLASH memory.

[Ancaritha]

I run into this problem quite frequently as well.  I’m always using the “Start debugger with GDB” option from inside Visual Studios.  I sometimes get that error when I haven’t even set any break points yet.  Usually I just hit stop and then “start debugger” again and it works fine, but on occasion I’ve had to flash the entire chip using the ST-Link Utility and then it’ll work.

I was running a year old version of OpenOCD, which I just updated to the latest.  I’m hoping that’s the issue but knowing about that “info breakpoints” command might be useful, see if there is somehow a disconnect between what Visual Studios thinks it has for breakpoints vs what GDB thinks it has.

[support]

There are indeed a few commands and settings that would indeed result in using extra hardware breakpoints. The “info breakpoints” command together with the gdb session log should fully explain them though.

[Author]

Posts