Workaround for “Error in final launch sequence: Cannot execute this command without a live selected thread.”

Posted on by

Recently I have been running into the following error message in Eclipse when I started the GDB debugger:

Error in Final Launch Sequence

Error in Final Launch Sequence

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:

Disabled Continue in Launch Configuration

Disabled Continue in 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
monitor-sleep-500

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 🙂

7 thoughts on “Workaround for “Error in final launch sequence: Cannot execute this command without a live selected thread.””

  1. 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

    Like

    Reply ↓

    • 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

      Like

      Reply ↓

  2. 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!

    Like

    Reply ↓

  3. 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.”

    Like

    Reply ↓

    • 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.

      Like

      Reply ↓

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.