Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
The error details do not show much more:
Error in final launch sequence
Failed to execute MI command:
continue
Error message from debugger back end:
Cannot execute this command without a live selected thread.
Failed to execute MI command:
continue
Error message from debugger back end:
Cannot execute this command without a live selected thread.
Cannot execute this command without a live selected thread.
It does not happen all the time, but it happens often with the Segger J-Link GDB server. It does not happen for ‘small’ programs (say less than 50 KByte). But it happens more often for larger programs (say > 100 KByte of FLASH).
I have enabled GDB Traces (see “Board Bring-Up Tips, GDB Logs and Traces in Eclipse” how to enable GDB Traces) to get more information about the problem:
688,887 (gdb) 688,888 &"flushreg\n" 688,888 ~"Register cache flushed.\n" 688,888 45^done 688,888 (gdb) 688,888 &"continue\n" 688,888 ~"Continuing.\n" 688,888 &"Cannot execute this command without a live selected thread.\n" 688,888 46^error,msg="Cannot execute this command without a live selected thread." 688,888 (gdb) 688,889 47-gdb-exit 688,898 47^exit 688,906 =thread-group-exited,id="i1"
Googling around, it seems that GDB throws this message if GDB receives a command, but has not initialized properly yet. So to me it seems that GDB is still busy with doing things after the download, and then it receives a command (in my case the ‘continue’ command), and is not ready yet.
The problem is that with that error message above, I have to restart the download/flashing again.
Workaround
I have not found a solution, but found at least a workaround. Because there seems to be a race condition with the download and the ‘continue’ execution, I have disabled the ‘continue’ in the GNU ARM Eclipse/GDB launch configuration:
That way, GDB is not instructed to do a ‘continue’ after the download. So it will stay on the reset vector/startup. Then I simply do a ‘continue’ in the debugger UI. I searched for a ‘wait for x ms’ function in the GDB command list, but have not found anything suitable for this situation. That would have been another workaround: say wait 500 ms after the download until executing the ‘continue’ command.
Thanks to John (see comments) there is an even better solution: The Segger GDB server accepts a timeout command, e.g. to wait 500 ms:
monitor sleep 500
That way, the problem was solved for me too :-).
Summary
There seems to be a timing problem between the GDB server and client. As a workaround I do not configure GDB to continue execution after downloading.
Happy Continuing 🙂
According to the J-Link User Guide, the following GDB command should deliver a 500ms pause when using the J-Link GDB server:
monitor sleep 500
Regardless of the GDB server in use, the following GDB command would deliver a 1 second pause on a Windows host:
shell timeout /nobreak /t 1
and the equivalent command on a Linux host would be:
shell sleep 1
LikeLike
Hi John,
incredible! I was looking for something like this for a long time, but somehow missed that monitor command. It works perfectly with the Segger J-Link :-).
The other approach with the GDB command did not work:
392,279 &”shell timeout /nobreak /t 5\n”
392,295 &”timeout /nobreak /t 5 exited with status 1\n”
But the Segger monitor command works, so I’m good for now, and I have updated the article.
Many thanks again for sharing that idea,
Erich
LikeLike
Hi Erich,
I have noticed another issue along similar lines that you had seen here when using J-link with an older project from KDS 3.0.0 opened in KDS 3.2.0.
I have a project in KDS 3.0.0 that uses KSDK 1.2 along with processor expert. That project I have been using a FRDM-K64F via the 10-pin ribbon to my target using PE micro tools. All that works fine. Target is a K64FX512M12.
I opened that same project in KDS 3.2.0 and I am trying to use a J-link plus with that project. ( KDS 3.2.0 I have done a KSDK 1.2 update.). However, I get similar sort of error window that pops up that you had encountered:
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Don’t know how to run. Try “help target”.
Don’t know how to run. Try “help target”.
I tried using the J-link with a demo project from the KSDK 2.1 examples and j-link and debugger worked flawlessly. I compared the two launch files (between demo project and my older project) and there is not really much difference other than project information. For fun I made them the same (using file comparison) with only project name differences and still get the same error above in my original project.
Seems like my last resort here is to create a new project and move things over from the old project, but wondering if anyone else has experienced this sort of problem or if there is a better way? We have several older projects we wish to move and I don’t like the idea of rebuilding each project from scratch. Maybe this is another possible blog item in terms of long term project management or migration upgrade strategies when using Freescale/NXP tool chains (especially what to avoid).
Erich, your blog is indispensable for us out here in the wild. Thank you!
LikeLike
Hi Mike,
it sounds that the J-Link is trying to connect to a target it does not know. Are you sure the ‘Device name’ in the Segger debugger launch settings is correct?
Other than that, if you can, you might send me your ‘working’ and ‘not working’ .launch files to the email address listed on the About page of this blog, and I try to spot the problem.
Erich
PS: Thanks, and I’m in the wild too 🙂
LikeLike
Hi Mike,
on another thought: it is possible to copy a working launch configuration into any project, see the basic steps in https://mcuoneclipse.com/2017/02/18/tips-for-making-copy-of-eclipse-cdt-projects-easier/
I hope this helps,
Erich
LikeLike
In STM32 workbench I have been getting the error.
“Cannot insert hardware breakpoint 1.\nCould not insert hardware breakpoints:\nYou may have requested too many hardware breakpoints/watchpoints.”
LikeLike
Have you tried removing some of your breakpoints? Depending on your STM32 device used, you only have 3 or 4 hardware breakpoints. Other than that, I suggest using a SEGGER J-Link as this comes with ‘unlimited’ flash breakpoints feature.
LikeLike