STM32 Break in problems again.

[jona]

I am now experiencing almost the same problems reported here:

STM32F4 GDB break-in request

Running VGDB 5.4R4 (build 3071) and the latest openOCD as of 4.24.19

STM32F7 DISCO and ST-LINK V2 Using the ST-LINK V2.1 driver.

Break-in or stopping the debug sessions take about a minute now. I believe this got even worse after updating openOCD.

Clicking on the sidebar does bring up the break-in dialog but breaking in still takes forever.

 

[jona]

Here’s a little more info.

I uninstalled VGDB and downloaded 5.4r5-trial.msi.

I installed that and reloaded my project.

It built, linked and downloaded so fast I was almost in tears!

Then, after working for about an hour or so.. it slowly began to take longer and longer to start a debug session and to stop it. Now, I am right back where I was this morning. Torture.

Does this shed any light? An issue I can fix?

[jona]

WHEW!!!! After switching USB hubs my workspace came back to life. What a relief!! I hope it lasts!

[support]

Good to know it works. We have indeed released an updated OpenOCD package recently, although it has passed our pre-release tests and had not triggered the behavior you described.

Generally, if you encounter intermittent errors, it’s almost always worth it to try another computer and another board and then try understanding the differences between the working and non-working setup. Many intermittent problems are often caused by factors outside VisualGDB’s control (e.g. wiring, power, USB connectivity, antivirus, disk corruption, etc) and it’s not something that VisualGDB could easily diagnose.

[jona]

Then, a couple of days later. It started acting up again.

[support]

Sorry, it looks like an intermittent problem caused by something about your setup. Unfortunately, it’s not something that VisualGDB could control and hence the only advice we could give is what was already suggested in the previous post.

[jona]

of course. ..

[jona]

just lookin’ for hints..

[Author]

Posts