Program randomly pauses and refuses to run after (handle_vCont_t, Thread already stopped)

[Thom Key]

Hey ST,

I've recently migrated to STM32CubeIDE as live variables tracking sounded very appealing to me.

Sadly this also has a (major) issue with debugging.

Let's say I had set a debug point at a certain line, 150 or so.

I think I removed it, afterwards if I run the debugger the program will run, but will consistently stop at 150.

I can verify this as I can pause it and see it being stuck there.

It will then say "handle_vCont_t, Thread already stopped".

The program will now not run, whether I use Resume, Step into or Step over.

The only way around this is to set a breakpoint before this and manually pass this line (instruction) with Step over.

This is incredibly annoying as I am trying to check timing with a logic analyzer.

I've tried some things, from using a different ST-LINK (V2 <> V3), to doing a clean all to creating and using a new debug configuration.

It seems as if there's a rogue breakpoint still there.

Any way around this?

I tried restarting STM32CubeIDE, but that didn't work.

Edit: The manual method doesn't work anymore :(

Edit2: OpenOCD works fine. But then I lose some tools...

[Reinhard Panhuber]

Anybody has an answer to that? I just experienced the very same behaviour :(

[RClar.112]

I'm having the exact same issue with:

Version: 1.3.0

Build: 5720_20200220_1053 (UTC)

OS: Linux, v.4.15.0-91-generic, x86_64 / gtk 3.22.30

Java version: 1.8.0_242

I've had to switch to using OpenOCD mode of the debugger to get around this problem for now. Would dearly like to have this bug squashed.

Cheers

Richard

[SShin.18]

Hello ST,

I'm also having same issue as stated by Thom Key , with:

stm32cubeide 1.2.0

if anyone have solution for this problem, please share with us.

[ramkumarkoppu]

Hi, I had the similar problem with Cube IDE. when I had this problem, I closed variables window and restated the debug then it started working normal.

[Rob Meades]

Another victim of the "handle_vCont_t, Thread already stopped" virus here.

Deleting the entire project, reimporting and re-building from scratch hasn't helped, somewhere the STM32Cube IDE (1.3.0) has a corrupt setting or some such and now every debug attempt is stopped dead by this error, making the entire tool useless.

Can anyone from ST help to resolve this please?

[Rob Meades]

I uninstalled everything with ST in the name, installed the STM32Cube ID again (happened to have moved up to 1.4.0, don't know if that's relevant) and now it is working again.

[MMici.1]

Hi Guys,

not sure about the actual cause but it seems to have something to do with removing breakpoints,

i.e. the program stops at a row where there used to be a breakpoint.

Here's a workaround to get rid of it (worked for me w/o reinstalling cube).

1) start debug

2) pause (should be at the row where your program is stuck)

3) toggle a breakpoint at that row

4) stop debug

5) run debug again, it should stop at the breakpoint (as expected)

6) toggle the breakpoint, i.e. remove it

7) continue debug - the program should now run ok

If the program gets stuck again at different row, it probably means that there was also

a breakpoint and you have to repeat the above process for this line as well.

Hope it works for you.

[SWyre.1]

I had the same problem as everyone else here but this fix does not seem to work for me. Maybe I'll just have to re-install. That's a real nuisance!

[sdbbs]

I also had a similar problem, Nucleo board with ST-LINK/V2, STM32CubeIDE 1.6. on Windows 10.

I notived that I also get "Warning: the current language does not match this frame." in the Debugger Console.

I found a link https://gcc-renesas.com/question/fix-warning-current-language-match-frame/ which is not online anymore, but the online search cache preserved "This seems to be an error caused by the inability to connect to port 61234 on your machine, port which is usually opened when the GDB server is ..." Also, https://stackoverflow.com/questions/27818914/eclipse-cannot-set-a-breakpoint-while-debbuging-arm mentions an old bug in Eclipse.

Ultimately, this motivated me to try:

> I've had to switch to using OpenOCD mode of the debugger to get around this problem for now.

This is the change that I did in the UI:

Now breakpoints hit where they should upon Run > Debug - but ironically, I still get "Warning: the current language does not match this frame." in the Debugger Console.