#56 GDB Configuration Hangs

Version 1.x
Evan Laske

I followed all of the tutorials from a clean installation of Eclipse, etc. I am using the latest versions of the GNU ARM Eclipse plugin tools along with OpenOCD and GNU Tools:

GNU Tools: 4.8 2014q1
OpenOCD: 0.8.0 (I have tried 0.7.0 in the tutorial as well)
GNU ARM Eclipse: Build from 4/24/14 (each plugin has a different version number).

Here's the problem: I configure the debug system like you have in the tutorials, then when I launch it, it never switches to the Debug perspective, which was odd. However, I notice at the bottom right, Eclipse still had "Launching blinkyF4cpp Debug: 94%"

When I investigate, I see it's saying "Launching : Configuring GDB."

I see output from OpenOCD that seems like it's working perfectly in either version:
Open On-Chip Debugger 0.7.0 (2013-05-05-10:41)
Licensed under GNU GPL v2
For bug reports, read
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v19 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.889334
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

The output from GDB traces:
429,539 2-environment-cd C:/Users/Evan/Workspaces/eclipse/CDT/blinkyF4cpp
429,540 2^done
429,541 (gdb)
429,541 3-gdb-set breakpoint pending on
429,550 3^done
429,550 (gdb)
429,550 4-enable-pretty-printing
429,560 4^done
429,560 (gdb)
429,560 5-gdb-set python print-stack none
429,570 5^done
429,570 (gdb)
429,570 6-gdb-set print object on
429,580 6^done
429,580 (gdb)
429,580 7-gdb-set print sevenbit-strings on
429,590 7^done
429,590 (gdb)
429,590 8-gdb-set charset ISO-8859-1
429,600 8^done
429,600 (gdb)
429,600 9set mem inaccessible-by-default off
429,600 10source .gdbinit
429,610 &"set mem inaccessible-by-default off\n"
429,610 =cmd-param-changed,param="mem inaccessible-by-default",value="off"
429,610 9^done
429,610 (gdb)
429,610 &"source .gdbinit\n"
429,610 &".gdbinit: No such file or directory.\n"
429,610 10^error,msg=".gdbinit: No such file or directory."
429,610 (gdb)
429,610 11-gdb-set auto-solib-add on
429,620 11^done
429,620 (gdb)
429,621 12-target-select remote localhost:3333

443,634 ~"Ignoring packet error, continuing...\n"
443,634 &"warning: unrecognized item \"timeout\" in \"qSupported\" response\n"
457,635 ~"Ignoring packet error, continuing...\n"
471,636 ~"Ignoring packet error, continuing...\n"
485,637 ~"Ignoring packet error, continuing...\n"
499,638 ~"Ignoring packet error, continuing...\n"
513,638 ~"Ignoring packet error, continuing...\n"
513,638 =thread-group-started,id="i1",pid="42000"
513,638 =thread-created,id="1",group-id="i1"
513,638 &"warning: Invalid remote reply: timeout\n"
513,639 13-list-thread-groups --available

There is no output from the third console window for arm-none-eabi-gdb.

I'm not quite sure what to make of this, since it seems that everything is configured correctly, as I've followed the tutorials. This problem doesn't seem to show itself on any of the FAQs or troubleshooting suggestions...

The only other things I've done to try to fix this has been to install the "C/C++ GDB Hardware Debugging" plugin, but that doesn't seem to have fixed it, only given me another option to try to configure a debug session.

PS: The project is also configured in the same way as the tutorial for setting up an STM32Fx project. Also, my environment is Eclipse Kepler release 2: 20140224-0627 and Windows 7 x64.


  • Evan Laske

    Evan Laske - 2014-05-25

    I installed the older 2013q4 version that you have in some of your examples, and it still has the same problem. I switched the PATH variable to point to this one in the project settings (C/C++ Build -> Environment).

  • Evan Laske

    Evan Laske - 2014-05-25

    I spent at least two days working on trying to solve that problem, and just after I report this support ticket, it just randomly starts working.

    When it did work for that first time, I noticed it still had OpenOCD 0.7.0 and GNU Tools 4.8 2013q4.

    When I changed to 0.8.0 and 2014q1, the problem came back. Changing them back to 0.7.0 and 2013q4 didn't solve the problem, though.

    I think for some reason, if you change one of these Eclipse settings, the computer must need to be restarted. Whenever I changed any of these settings in my testing, I would apply them and then restart Eclipse, but not my computer (because one would think you wouldn't need to).

    I will try further investigation with the newer tools and restarting Eclipse / my computer.

  • Evan Laske

    Evan Laske - 2014-05-25

    After reconfiguring back to the working versions (0.7.0 and 2013q4) and it not working, I double-checked that the right executables were getting called; they were.

    I restarted in this configuration and then everything worked just fine again.

    So, then I updated the OpenOCD reference to 0.8.0, restarted Eclipse only, and it seems to work. The 2013q4 GDB is still getting called, but 0.8.0 OpenOCD is getting called.

    To be sure this continued to work, I tried terminating the session / reconnecting several times. This brought up another issue / bug / feature request: it should return you from the Debug perspective when the Debug session is terminated / disconnected. Also, when I do disconnect, the software on the embedded controller stops.

    Anyway, I also restarted Eclipse with this 0.8.0/2013q4 configuration multiple times and tested it. All is well.

    Then, I edited the project's Environment PATH (Project Properties -> C/C++ Build -> Environment) to point to the 2014q1 path again. (The Global path in -> Settings -> Toolchains was untouched from before, and still said 2014q1). Then I restarted Eclipse. When I clicked Debug again, all seems to work. No other restart needed. When double-checking in Task Manager, the arm-none-eabi-gdb.exe executing was pointing to the correct 2014q1 folder and openocd was pointing to the 0.8.0 folder.

    I've attached a text file of the different console windows during this final, successful test. This was just hitting Debug, then hitting play, then pause, then terminate on the standard blinky template for the STM32F4 Discovery board. The board blinked the LED during the time running.

  • Liviu Ionescu (ilg)

    Hello Evan,

    Thank you for taking the time to diagnose the problem. I'm not sure I fully understand it, but it seems that the gdb launcher sometimes fails. Is that right?

    From your initial log, the problem seems to be caused by a mismatch between the gdb client and the gdb server, in other words openocd does not accept the commands.

    This seems to be caused by some delays that occur inside openocd, that might be related to some usb driver issues, which explain why a system reset helps.

    When this affects you, the only suggestion I have is to avoid openocd and use a professional solution, like J-Link.

    On the other hand, manually changing the project PATH in the project settings obviously interferes with the automatic mechanism used to set the path based on the toolchain path, so it is recommended to avoid it, and either change the PATH for the entire workspace or change the toolchain path.

    Could you summarise the bugs/feature requests, to try to get a better understanding if they are related to the plug-in or not?

    Last edit: Liviu Ionescu (ilg) 2014-05-25
  • Liviu Ionescu (ilg)

    • status: open --> accepted
    • assigned_to: Liviu Ionescu (ilg)
  • Liviu Ionescu (ilg)


    We did some more tests, and one possible scenario that exhibits a similar behaviour is caused by a hanged openocd.

    In case you encounter this situation again, please check the processes and in case you find an openocd, kill it.

  • Evan Laske

    Evan Laske - 2014-05-29

    The USB problem you indicated makes a lot of sense. It doesn't seem that OpenOCD is hanged, but I guess I have no way of testing that, really...

    I wasn't sure J-Link would work with ST-Link? Is it true that it does? If so, I'll have to try that out instead, I was under the assumption it only worked with the segger debugger.

    If anything, the bug / feature request related to this would be an edit to the wiki pages to make sure any known issues like this were there or in the FAQ (I didn't find any). Though the problem I guess could reside in the launcher of GDB (i.e. the plug-in).

    Do you have any suggested way to test to see if it's the USB issue you suggested?

  • Liviu Ionescu (ilg)

    It doesn't seem that OpenOCD is hanged, but I guess I have no way of testing that, really..

    you do, a hanged openocd can be detected by closing Eclipse and inspecting the running processes.

    ... J-Link would work with ST-Link?

    Segger software works only with J-Link.

    Though the problem I guess could reside in the launcher of GDB (i.e. the plug-in).

    might be, but the chances are slim, exactly the same launcher code works with J-Link, which does not hang.

    Do you have any suggested way to test to see if it's the USB issue you suggested?

    yes, when launching fails with "Launching blinkyF4cpp Debug: 94%", wait for it to time out, then close eclipse and inspect the running processes. If you do see one openocd there, kill it. Restart Eclipse and retry starting the debug session.

    one of the many problems openocd has, is that it does not detect properly when another instance of itself is running. this means that it does not complain when you start it again, everything seems fine but it does not work.

    if you never detect a hanged openocd, then the problem might be with the usb drivers, and I suggest you reinstall the original ST drivers and double check you do not have an unusual usb configuration. (windows usb drivers are often conflicting).

  • Liviu Ionescu (ilg)

    Even, do you have any news on this issue?

  • Evan Laske

    Evan Laske - 2014-06-24

    I haven't gotten a chance to touch it in a few weeks, actually. I'll try to test things out as soon as I can. I don't have a J-Link, only the ST-Link debugger, though.

  • Evan Laske

    Evan Laske - 2014-07-13

    So, I finally got it to replicate the problem I had. It doesn't time out any more; I waited 10 minutes, and it just hung. When I killed it through Eclipse, it killed all the correct processes.

    I tried reinstalling the device drivers, and that didn't work either.

    I'm going to make sure that the restarting still solves the problem...

    • Liviu Ionescu (ilg)

      did you use the latest plug-in version?

  • Evan Laske

    Evan Laske - 2014-07-13

    Yeah, so far, if this occurs, I have to restart the computer. For reference, the system uptime was 3 days, 15 hours.

    • Liviu Ionescu (ilg)

      try to just kill the hanged openocd process, it should be enough.

  • Liviu Ionescu (ilg)

    the behaviour that you are presenting is typical for multiple openocd processes.

    you must be sure that when you start a debug session, there is no other openocd, started manually, or from another session, hanging around.

  • Evan Laske

    Evan Laske - 2014-07-14

    Ok, so most of the debugging I was doing working from home so far. Now I've got it set up at work, I've updated the plugin (I didn't notice there was a new one since last time), and now it gets to 94% for a bit, and then comes up with this error text:

    Error in final launch sequence
    Failed to execute MI command:
    -target-select remote localhost:3333

    Error message from debugger back end:
    localhost:3333: The system tried to join a drive to a directory on a joined drive.
    localhost:3333: The system tried to join a drive to a directory on a joined drive.

  • Liviu Ionescu (ilg)

    openocd dies prematurely, so the gdb client cannot connect to it.

    start it by hand outside eclipse and check if the client can connect to it.

  • Evan Laske

    Evan Laske - 2014-07-14

    After rebooting the device (unplugging / and replugging the STLink + device), the debugger gets stuck at 62% - or what looks like the GDB configuration / launching.

    When it get stuck there, there's no arm-..gdb.exe process, gdb.exe process, or openocd.exe process.

    Rebooting Eclipse after that and re-launching the debugger gives an error:
    Error in services launch sequence
    GDB prompt not read

    • Liviu Ionescu (ilg)

      most probably openocd is not happy with the command line options you pass and quits.

      to see the error message, start it by hand with exactly the same command line.

      • Evan Laske

        Evan Laske - 2014-07-14

        That's good to know. This error message, I've not seen before, so I assumed it was added by you? If so, I'll put in a feature request to add the openocd output to the error dialog.

        I'll make sure to double check and get back to you. The other error I got stopped me from doing that.

        • Liviu Ionescu (ilg)

          I'll put in a feature request to add the openocd output to the error dialog.

          it is already there as [Bugs:#107]

  • Evan Laske

    Evan Laske - 2014-07-14

    PS, I had errors with the OpenOCD configuration file before, but the errors showed up in Eclipse with the rest of the output, but that was before updating the plug in. So, if it got that far before, I'd be able to see OpenOCD's output.

  • Liviu Ionescu (ilg)

    This error message, I've not seen before, so I assumed it was added by you?

    I added two messages, one informing that the Config options: field is empty, and one asking to check the configuration options, issued when the openocd is terminated before trying to start the gdb client.

    unfortunately openocd behaviour is far more unstable than the jlink gdb server, and borrowing the code from the jlink plug-in seems not enough :-(

  • Liviu Ionescu (ilg)

    • status: accepted --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks