Eclipse error in final launch sequence

MCU on Eclipse

Everything on Eclipse, Microcontrollers and Software

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

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:

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:

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

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:

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.

Like this:

About Erich Styger

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

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:

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 5n”
392,295 &”timeout /nobreak /t 5 exited with status 1n”

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

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!

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 🙂

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

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

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.

What do you think? Cancel reply

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

Источник

Error in final launch sequence failed to execute mi command

Community

Participate

Eclipse IDE

Home » Language IDEs » C / C++ IDE (CDT) » Error in final launch sequence Failed to execute MI command (When trying to flash program on to a particular MCU we are facing this issue.)

Error in final launch sequence Failed to execute MI command [message #1084318]	Sun, 11 August 2013 10:04
Karunakar Reddy Messages: 1 Registered: August 2013
Hello i am very new to eclipse. Currently using code sourcery as IDE to develop C/C++ applications.We are able to build the application successfully.But when we try to flash the program on to MCU the below error is displayed. Error in final launch sequence Failed to execute MI command: detach Error message from debugger back end: Can’t detach process. Can’t detach process. Any one who has faced such kind of issue or are very familiar with eclipse please help me out. Thanks in advance. Источник Error in final launch sequence failed to execute mi command Community Participate Eclipse IDE Breadcrumbs Home » Language IDEs » C / C++ IDE (CDT) » Failure to execute MI command during Debug — Helios Failure to execute MI command during Debug — Helios [message #1723712] Wed, 17 February 2016 10:41 Vishesh Garg Messages: 3 Registered: February 2016 When try to launch a debug session by attaching to a remote process, I get the following error: I saw a similar issue being reported in the thread https://www.eclipse.org/forums/index.php/t/795327/. It was mentioned in the response to disable «Set breakpoint at» to avoid setting up of breakpoint at main. However, I find no such option in the Helios version of Eclipse. Are there any other ways to get around this problem? Re: Failure to execute MI command during Debug — Helios [message #1723812 is a reply to message #1723792] Thu, 18 February 2016 08:29 Jonah Graham Messages: 415 Registered: June 2014 Hello Vishesh, Sorry you are having trouble with CDT. Hopefully someone here can help. I didn’t answer yesterday because I have no (easy) access to Helios to try stuff out. I had assumed you must be using a vendor provided Eclipse that had not been updated for a long time, but now I see you are using a very old Eclipse with a (relatively?) new Ubuntu and therefore relatively new GDB. Helios is about 6 years old, around when GDB 7.0 came out. Eclipse Mars officially supports GDB 7.1+ and unofficially GDB 6.6+. Please update to Eclipse Mars. If you cannot update, please let me know and I can consider if I can help further. It would help in this case to explain what aspect prevents you from updating. Please also provide the version of GDB you are using. Re: Failure to execute MI command during Debug — Helios [message #1723824 is a reply to message #1723812] Thu, 18 February 2016 09:35 David Vavra Messages: 1427 Registered: October 2012 It’s been a long time since I’ve used Helios (even my older systems have Juno) but my recollection is the option is there somewhere, perhaps on a different tab. I don’t recall having to attach to a running task though. Stopping at main might not be what is going on. It may be an entirely different issue. There is a console window for GDB (two actually) selectable through a drop down menu in the Console View. It may give some indication what GDB (or Eclipse through GDB) is trying to do. Check the .gdbinit file. There may be something in it that is triggering it. If there is, trying to attach while running GDB by itself would also have the same problem. Have you tried running GDB by itself and try to attach? Yes, do upgrade if you can.If you can’t, try to keep the tools originally used by Helios intact or you may find yourself facing compatibility problems. EDIT: Still can’t type. [Updated on: Thu, 18 February 2016 09:40] Re: Failure to execute MI command during Debug — Helios [message #1723834 is a reply to message #1723829] Thu, 18 February 2016 10:53 David Vavra Messages: 1427 Registered: October 2012 Actually the link given by the OP (https://www.eclipse.org/forums/index.php/t/795327/) does say there is one. The post is dated in July, 2014 and the Eclipse version being discussed was Kepler. No one complained about it being incorrect and someone even thanked the responder. I have just noticed though it makes a reference to a Startup subtab. There isn’t one normally that I know of. It might be something peculiar to ARM or perhaps even OSX. Re: Failure to execute MI command during Debug — Helios [message #1723845 is a reply to message #1723834] Thu, 18 February 2016 12:51 Jonah Graham Messages: 415 Registered: June 2014 That link is referring to remote connection (i.e. C/C++ Remote Application), different flow than attach (i.e. C/C++ Attach to Application). An example of remote is when connecting to gdbserver (or something else implementing RSP, such as Segger) Re: Failure to execute MI command during Debug — Helios [message #1723869 is a reply to message #1723845] Thu, 18 February 2016 15:42 Marc Khouzam Messages: 357 Registered: July 2009 Jonah Graham wrote on Thu, 18 February 2016 12:51 That link is referring to remote connection (i.e. C/C++ Remote Application), different flow than attach (i.e. C/C++ Attach to Application). An example of remote is when connecting to gdbserver (or something else implementing RSP, such as Segger) Right. When doing a «C/C++ Application» or «C/C++ Remote Application» type of launch, CDT will actually start the process for you and therefore, the user can specify if CDT should stop the process at «main» (or whatever other method you choose). For «C/C++ Attach to Application» CDT is being asked to attach to a running process. In that case, it does not make sense to have an option to «stop on startup» since the process is already running. -target-attach 28175 Error message from debugger back end: Cannot access memory at address 0x5f31534b52455361 is caused by GDB. I’m not sure what it is trying to do exactly, but it seems that it cannot attach to the process for some reason. If this happens again with a newer version of Eclipse, I would recommend trying manually with GDB to see if your target even allows to attach to a process. Re: Failure to execute MI command during Debug — Helios [message #1789932 is a reply to message #1723869] Thu, 31 May 2018 22:00 Gregg Wonderly Messages: 3 Registered: May 2018 Actually, it still does not work. The problem is that the —attach doesn’t have a correct argument implementation. There should just be a checkbox labeled «Attach to Pid: » with the ability to enter the PID to attach to. That should in turn cause the «download app» to be unchecked, and the requirement for a working remote path to the executable to be voided. Right now, there are a couple of ways to get a valid command line, that I found, but none are allowing the debugging session to actually work. Oxygen is confused. You can add —attach to the «Gdbserver options:» field on the Gdbserver Settings sub tab of the Debugger tab, and then either put the PID after the port number (then you see this error above), or you can place the PID in the «Remote Absolute file Path for C/C++ Application:» field on the Main tab. In this last case, it shows connected and their are «stop» buttons active, but no «pause» or «resume» buttons. The Debug pane doesn’t show any thread details either, so its really not working. Источник Adblock detector

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 &"flushregn"
688,888 ~"Register cache flushed.n"
688,888 45^done
688,888 (gdb) 
688,888 &"continuen"
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.

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 🙂

1

Вот как происходит запуск ST-LINK_gdbserver

Atollic TrueSTUDIO gdbserver for ST-Link.  Version 1.7.0 Pro
Copyright 2010-2012, Atollic AB.


Starting server with the following options:
        Persistant Mode            : Enabled
        LogFile Name               : debug.log
        Logging Level              : 31
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled

Connecting to the ST-Link Debugger... OK
Waiting for debugger connection...

В общем эксперимент показал что такую ошибку выдает даже если не запускать ST-LINK_gdbserver вообще. Тоесть он его не видит или отладка вылетает еще до попытки связи с ним.

Попробовал в настройках debug выбрать Standart GDB Hardware Debugging Launcher, по умолчанию было GDB (DSF) Hardware Debugging Launcher.

Теперь с ST-LINK_gdbserver связывается но тот сразу закрывает соединение.

Error while waiting for debugger connection.
Shutting down...
Debugger connection lost.
Shutting down...

Изменено 8 февраля, 2013 пользователем flopix

_________________
На практике можно не успеть сделать того, что можно хорошо обосновать в теории. Но без практики теория может отдаляться от нее, и когда они встретятся снова — не узнает даже неприкосновенное шампанское профессора в лаборатории. Моя практика: robofeya.ru