search

Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
1k stars 239 forks source link

not aware of hardware debugging limitations? #407

Closed rk-exxec closed 3 years ago

rk-exxec commented 3 years ago

Hey, I don't know if this has been reported yet. I am using this extension to debug my Tiva Launchpad which has 6 hardware breakpoints.

I get strange behavior if I select more than that in the editor. The debugging starts with loading the binary but then stops working. The controls show the pause button, but I cannot pause it. The controller does not appear to be running the program though.

Removing some breakpoints and restarting fixes the issue.

Is there a way to check the number of breakpoints before loading or when changing them while running? The OpenOCD command line displays the capabilities on launch:

For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 32765 kHz
Info : ICDI Firmware version: 9270
Info : tm4c123gh6pm.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections

I know this is probably easy to mitigate on my own, but some may not be aware of these limitations.

Marus commented 3 years ago

Yes, this is a current limitation. Unfortunately there are not a lot of great ways to handle this - while we can detect the number of HW breakpoints available it would still have to make arbitrary decisions on what breakpoints we actually pay attention to. Then there are debug probes/servers (like some J-Link) that can work around the HW breakpoints issue - so it may not even be an issue in all cases.

One thing that I might consider is giving a warning in the UI that they have likely used all of the HW breakpoints and may run into issues.

rk-exxec commented 3 years ago

I think a notification would be sufficient. And maybe block setting new breakpoints or auto-disable them if the user specifies in the settings?

haneefdm commented 3 years ago

I don't have a good solution to this. Most people know the limitations with breakpoints in their embedded processor.