@sov1178 Looking at the logs, in the first one there are two things:

• Thread 1 seems to exit early so we get the following error, I don't think that matters though.

->=thread-exited,id="1",group-id="i1"
1: (1038) ->=thread-created,id="2",group-id="i1"
1: (1038) ->=thread-created,id="3",group-id="i1"
1: (1038) ->=thread-created,id="4",group-id="i1"
1: (1038) ->=thread-created,id="5",group-id="i1"
1: (1039) ->=thread-created,id="6",group-id="i1"
1: (1039) ->=thread-created,id="7",group-id="i1"
1: (1039) ->=thread-created,id="8",group-id="i1"

and

E output: {"category":"stderr","output":"ERROR: Unable to start debugging. Failed to find thread 1 for break event\r\n","data":null,"type":"output"}
ERROR: Unable to start debugging. Failed to find thread 1 for break event

• At the bottom of the first log, it looks like the thread-group that all the threads are part of has exited leaving no running threads so we request logout:

1: (1293) ->=thread-group-exited,id="i1"
1: (1296) <-logout

I would expect that if other threads are running, the thread-group that they belong to, in this instance i1 doesn't exit while its running.

I don't know if this is an issue in our code or an issue in the arm gdb version.

Thread 1 seems to exit early so we get the following error

@pieandcakes Thread 1 will always exit as soon as OS starts - it is not the real thread. OpenOCD makes fake thread to tell gdb that something is running before the OS starts. So it is OK. I do not know what caused thread-group exit message. I will see OpenOCD logs and write more.

I don't know if this is an issue in our code or an issue in the arm gdb version.

If I run gdb+OpenOCD with the same project/settings but without VSCode everything works finely, so it looks like it is related to VSCode.

Bump.

Exact same problem. Any solution?

I see the same on ESP32, but it disappears when I disable FreeRTOS support in the board configuration file. Sorry, don't have an ARM board at hand.

*) in my case "set ESP32_RTOS none"