Hang/crash when using >3 breakpoints

[zzattack]

Using latest openocd to debug a stm32f0 device, whenever I create a 4th breakpoint I’m presented with a “GDB timeout”/”Break-in request taking too long” message after which I can only stop debugging and restart my session. Is this a limitation of the debugging capabilities on this microcontroller, or an issue with VisualGDB? Is there a way to prevent/warn upon the creation of more breakpoints than supported, so as to not lock up the session?

[support]

Hi,

The restriction for the amount of simultaneous breakpoints in FLASH is a limitation of the microcontroller. However it should clearly show a message like “too many hardware breakpoints” and not hang.

Could you please try stopping the program at a breakpoint, adding more breakpoints to exceed the limit and pressing F5 to continue? Does it hang as well? Do you get the same behavior on all devices?

[zzattack]

If I do so, I get a message “Command aborted.” in the GDB session window. When I then try to remove the extra breakpoints, I get into the same behavior where it hangs.

This is my first project with VisualGDB, haven’t tested it on another microcontroller before.

• This reply was modified 7 years, 5 months ago by zzattack.

[support]

Hi,

Sorry about that. Based on your description this looks like a potential problem with the board or the USB driver, so trying a different board or a different machine might easily solve this.

If this is not possible, please do the following to diagnose this:

• Start debugging as usual
• Press “break all” to cause the “Command aborted” error
• Switch the GDB Session window to “All GDB Interaction”
• Copy all contents of the GDB Session window and the OpenOCD window and post it here

This should help us understand what could be causing this and give you further advice.

[zzattack]

http://pastebin.com/N6DBBmQS

 

Here’s the log.

[support]

Hi,

Thanks very much for reporting this. It looks like the new gdb reports the ‘failed to resume session’ events slightly differently and this totally confuses VisualGDB.

We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1324.msi

It will also be included in the next maintenance release of v5.2.

[zzattack]

Excellent, I can confirm this addresses the issue. Thanks for the fast resolution!

[Author]

Posts