STM32F4 GDB break-in request

[parsec67]

Hi,

With the VisualGDB 5.4 releases (R2 and the previews that I have tried) I am having frequent problems with setting breakpoints on running code. Can’t recall that I ever encountered this in earlier releases, esp. 5.2R9 was very stable in this regard. Changing ‘Minimal delay…’ in General settings to 300/500/1000 has no effect.

Another thing is that if the break-in request takes too long or if I cancel it I am after that point also unable to do a Break all. The only remaining option at this point is to stop debugging.

Lastly I have noticed that in a few instances, just clicking the VS editor side bar to try to insert a breakpoint will halt code execution, after which the ‘break-in request is taking too long’ dialog is shown.

[support]

This looks like a known issue. It should not trigger in v5.4R2, however it would be present in some of the daily builds after it. We are currently refactoring the initialization logic of VisualGDB to make different components initialize on-demand and completely eliminate any delays during Visual Studio startups, so some of the daily builds were indeed buggy.

Please try this one, it has the breakpoint problem fixed: VisualGDB-5.4.103.2958.msi

[parsec67]

Definite improvement, thanks. Been debugging the whole day and I see the break-in dialog only occasionally but it always succeeds after a few seconds. I also noticed in my settings that I had programmer set to ST-Link v2.1 which used to work fine but is now reported as deprecated. Perhaps this was related to my problem? At any rate I have switched to ST-Link v2 and it appears to be solid.

Another thing I noticed is that VStudio loads quickly now compared to before. Just curious if you made some changes to improve startup times?

[support]

Thanks for the update. The break-in dialog does not always indicate a problem. It simply means that the gdb stub (i.e. OpenOCD) is taking some time to communicate to the hardware and wait for it to stop (in the previous version that branch was never taken due to a bug on our side).

The “deprecated” message is related to the internal OpenOCD script names and can be ignored. We will update our interface description files accordingly in one of the next releases of the OpenOCD package.

Indeed, the new build fully enables the on-demand loading, so Visual Studio startup will no longer be slowed down by VisualGDB. It will only initialize itself when running a wizard, clicking on a VisualGDB-related menu command, or opening a VisualGDB-related project.

[Author]

Posts