call to openOCD doesnt use quotes for arguments and no console output

[marcel-kanter]

I've installed eclipse completely fresh.

After creating a new debug configuration and starting it, eclipse show an error. openocd exited with (1). See openocd console for details.

BUT the console is empty.

Running openocd with the -s and -f parameter from the workspace directory works. Driver gets loaded and the connection opened. So openocd is working properly (It worked already with an orlder version of the MCU eclipse plugin - before and after the risc-v got included into the plugin)

Even with the arguments quoted, it works:

openocd -c "gdb_port 3333" -c "telnet_port 4444" -c "tcl_port 6666" -s "D:/bin/openocd/scripts" -f "board/stm32f4discovery.cfg"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-17:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J29S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.898996
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections

But with the echo it doesn even do enything

openocd -c "gdb_port 3333" -c "telnet_port 4444" -c "tcl_port 6666" -s "D:/bin/openocd/scripts" -f "board/stm32f4discovery.cfg" -c "echo 'Started by GNU MCU Eclipse'"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-17:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Then I put the path to openocd to the PATH env variable. Didn't help with eclipse.

After replacing openocd with echo it prints the following into console:

-c gdb_port 3333 -c telnet_port 4444 -c tcl_port 6666 -s D:/bin/openocd/scripts -f board/stm32f4discovery.cfg -c echo Started by GNU MCU Eclipse

That shows that it gets called without any quotes.

After doing a search I found an article, complaining about the same problem from 2016, so I copied the newest version of openocd to my drive, to check whether the new version behaves diefferently (old version was 2020-05-03). The old version was from the same site too.

Nope. Same problem.

C/C++ GCC Cross Compiler Support 10.1.0.202011181638 org.eclipse.cdt.build.crossgcc.feature.group
C/C++ GDB Hardware Debugging 10.1.0.202011291939 org.eclipse.cdt.debug.gdbjtag.feature.group
Eclipse Platform 4.18.0.I20201202-1800 org.eclipse.platform.ide
Embedded C/C++ Arm Cross Compiler 6.1.1.202101200825 org.eclipse.embedcdt.managedbuild.cross.arm.feature.group
Embedded C/C++ Core 6.1.1.202101200825 org.eclipse.embedcdt.feature.group
Embedded C/C++ OpenOCD Debugging 6.1.1.202101200825 org.eclipse.embedcdt.debug.gdbjtag.openocd.feature.group
PHP Development Tools (PDT) 7.2.0.202005271851 org.eclipse.php.feature.group
PyDev for Eclipse 8.1.0.202012051215 org.python.pydev.feature.feature.group
Wild Web Developer 0.10.5.202012011111 org.eclipse.wildwebdeveloper.feature.feature.group

eclipse.buildId=4.18.0.I20201202-1800

open jdk-13.0.1

windows 10 64 bit

Could You simply remove the last echo and put the other arguments into quotes?

[ilg-ul]

To correctly check how Eclipse calls applications, I suggest that instead of echoing the entire line, to write a simple shell script that prints the number of arguments and each argument on a single line.

[marcel-kanter]

Error in services launch sequence
Launching command [python echo.py -c gdb_port 3333 -c telnet_port 4444 -c tcl_port 6666 -s D:/bin/openocd/scripts -f board/stm32f4discovery.cfg -c echo "Started by GNU MCU Eclipse"] failed.
Launching command [python echo.py -c gdb_port 3333 -c telnet_port 4444 -c tcl_port 6666 -s D:/bin/openocd/scripts -f board/stm32f4discovery.cfg -c echo "Started by GNU MCU Eclipse"] failed.
Cannot run program "python echo.py" (in directory "D:\workspace\test-arm"): CreateProcess error=2, Das System kann die angegebene Datei nicht finden

[marcel-kanter]

... tricking eclipse into an error shows the command line without the quotes for the port commands...

[marcel-kanter]

And echo.py (As you mentioned)

import sys

for arg in sys.argv:
print(arg)

[ilg-ul]

tricking eclipse into an error shows the command line without the quotes for the port commands...

Find a way to run the echo script to double check.

[marcel-kanter]

Things get weird, I converted the script to an executable (renamed it to printi.py), the output:

D:\workspace\test-arm\printi.exe
-c
gdb_port 3333
-c
telnet_port 4444
-c
tcl_port 6666
-s
D:/bin/openocd/scripts
-f
board/stm32f4discovery.cfg
-c
echo Started
by
GNU
MCU
Eclipse

[marcel-kanter]

...so only the last part is split into several arguments...

[ilg-ul]

Eclipse starts OpenOCD correctly (at least it did for many years already), the problem occurs only if you start it manually.

[marcel-kanter]

Shouldnt it work then? But it doesnt, but did with the 2019-09 release. Is there any way to disable thr last echo commnd to openocd? Starting openocd from console with the echo doesnt work to.
The other commands about the ports get correctly to openocd. I debugged the hw with the manually started openocd and the gdb hardware debug config...

[ilg-ul]

The last echo message is needed to inform Eclipse when the GDB server is ready to accept commands.

It is difficult to tell what is wrong.

Can you provide more details on what you installed, what/how you configured, to try to reproduce the problem?

[marcel-kanter]

I tried the 2019-12 install with C/C++ Development Tools 9.10.0.201912051559 org.eclipse.cdt.feature.group Eclipse CDT
C/C++ GDB Hardware Debugging 9.10.0.201911010936 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT
Eclipse Platform 4.14.0.I20191210-0610 org.eclipse.platform.ide Eclipse.org
Embedded C/C++ ARM Cross Compiler (incubation) 2.7.1.202007271621 ilg.gnumcueclipse.managedbuild.cross.arm.feature.feature.group Eclipse Embedded CDT
Embedded C/C++ OpenOCD Debugging (incubation) 4.4.1.202007271621 ilg.gnumcueclipse.debug.gdbjtag.openocd.feature.feature.group Eclipse Embedded CDT
PHP Development Tools (PDT) 7.0.0.201912041612 org.eclipse.php.feature.group Eclipse PDT
PyDev for Eclipse 8.1.0.202012051215 org.python.pydev.feature.feature.group Fabio Zadrozny

IT worked with the newest openocd.

Exchanging openocd with the ergument printer i got:

printi
-c
gdb_port 3333
-c
telnet_port 4444
-c
tcl_port 6666
-f
board/st_nucleo_f4.cfg
-s
D:\bin\openocd\bin/../scripts
-c
echo "Started by GNU MCU Eclipse"

[marcel-kanter]

The differences: eclipse platform and the plugin version.
Updating the plugin to
Embedded C/C++ Arm Cross Compiler (incubation) 2.7.3.202010292017 ilg.gnumcueclipse.managedbuild.cross.arm.feature.feature.group Eclipse Embedded CDT
Embedded C/C++ OpenOCD Debugging (incubation) 4.4.2.202010292017 ilg.gnumcueclipse.debug.gdbjtag.openocd.feature.feature.group Eclipse Embedded CDT

Still works

[marcel-kanter]

Ok. It seems to bee a problem with the 6.x versions of the plugins or 4.18 version of eclipse

Download and extract the platform binary for windows from http://download.eclipse.org/eclipse/downloads/drops4/R-4.18-202012021800/

Start eclipse and create new workspace

Go to "install new software...", select "-- all available sites --- " and select:
Embedded C/C++ Arm Cross Compiler 6.0.0.202012080907 org.eclipse.embedcdt.managedbuild.cross.arm.feature.group Eclipse Embedded CDT
Embedded C/C++ Core 6.0.0.202012080907 org.eclipse.embedcdt.feature.group Eclipse Embedded CDT
Embedded C/C++ OpenOCD Debugging 6.0.0.202012080907 org.eclipse.embedcdt.debug.gdbjtag.openocd.feature.group Eclipse Embedded CDT

It takes a while and then create a new c/c++ project
select managed c++ build, leave the path empty

Then go into window preferences and configure the global paths under MCU.

Here some differences:
With 4.16, even compiling the empty project will at least list the include files in the project explorer
With 4.18 not

Now create a simple main.c with just int main(void) and _exit in it and compile. Gcc will complain about exit but generates an elf.

Then create an debug configuration gdb openocd debugging.
Configure the board with -f "board/stm32f4discovery.cfg" (any other script will work) and click on debug

With 4.16 the debug console opens with red text and openocd is running
With 4.18 the console is not opening and it complains with exit code 1

**EDIT: I used the matching versions of the embedded c/c++ or mcu eclipse plugins for the chosen eclipse platform ***

[ilg-ul]

Unfortunately I cannot reproduce your issue.

I downloaded the latest Windows Eclipse IDE for Embedded C/C++ Developers, created a stm32f4discovery blinky project, added the OpenOCD debug configuration, and the debug started as expected:

xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-17:29)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J14S0 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.891618
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024 kbytes
Info : flash size = 512 bytes
Warn : Prefer GDB command "target extended-remote 3333" instead of "target remote 3333"
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080002b8 msp: 0x20020000
semihosting is enabled

As seen above, Eclipse properly passes the Started by GNU MCU Eclipse message when starting OpenOCD, and later identifies it in the console output, to know when to start the GDB client.

[marcel-kanter]

But how about the way i discribed?
Is this a combinational problem, so that specific versions must be used?

[marcel-kanter]

Hah, I got it. Could you please add a dependency to the following two packages?

C/C++ Development Tools 10.1.0.202012020953 org.eclipse.cdt.feature.group Eclipse CDT
C/C++ GDB Hardware Debugging 10.1.0.202011291939 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT

Without the Development Tools eclipse can compile correctly, but cannot find gdb for some reason (albeit it is in the same directory as g++ or gcc). If you trick it via PATH to find gdb it does not start openocd correctly.

This is the minimal package list for a minimal embedded c/c++ eclipse:

C/C++ Development Tools 10.1.0.202012020953 org.eclipse.cdt.feature.group Eclipse CDT
C/C++ GDB Hardware Debugging 10.1.0.202011291939 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT
Eclipse Platform 4.18.0.I20201202-1800 org.eclipse.platform.ide Eclipse.org
Embedded C/C++ Arm Cross Compiler 6.0.0.202012080907 org.eclipse.embedcdt.managedbuild.cross.arm.feature.group Eclipse Embedded CDT
Embedded C/C++ Core 6.0.0.202012080907 org.eclipse.embedcdt.feature.group Eclipse Embedded CDT
Embedded C/C++ OpenOCD Debugging 6.0.0.202012080907 org.eclipse.embedcdt.debug.gdbjtag.openocd.feature.group Eclipse Embedded CDT

[ilg-ul]

@jonahgraham Jonah, do you understand where the problem might be?

[marcel-kanter]

Maybe its the development tools alone. I first installed only the embedded packets, then the gdb hardware debugging and finally the development tools packet (which in the end made it work).

[ilg-ul]

Could you check the workspace/.metadata/.log for anything unusual? If there are missing dependencies, there might be some exceptions.

[jonahgraham]

@jonahgraham Jonah, do you understand where the problem might be?

No - but I will experiment and see what I can figure out.

[ilg-ul]

I tried the 2019-12 install with C/C++ Development Tools 9.10.0.201912051559 org.eclipse.cdt.feature.group Eclipse CDT

I'm afraid you are trying to mix various older versions.

The current Embedded CDT plug-ins (v6.x) require CDT 10.x, part of Eclipse 2020-09.

[jonahgraham]

I tried the 2019-12 install with C/C++ Development Tools 9.10.0.201912051559 org.eclipse.cdt.feature.group Eclipse CDT

I'm afraid you are trying to mix various older versions.

The current Embedded CDT plug-ins (v6.x) require CDT 10.x, part of Eclipse 2020-09.

I take it from this comment you have identified the issue?

If so, I won't be doing any further looking at this.

[ilg-ul]

I don't know if I identified the issue, since I don't know what exactly @marcel-kanter tried to achieve by trying to manually install a selection of the features, I just spotted that those are older versions.

[marcel-kanter]

Please be aware that during my tests I used several versions of eclipse platform and the matching embedded tools. Don't mix the versions of differend posts. I always started with a fresh extract of the platform (e.g. 2012-06 or 2012-12 version) and installed the matching plugins for either version, as it is displayed in the "Install new software dialog of eclipse". The mechanism behind that resolves dependencies (e.g. the platform 2012-12 and the 10.1 version of c/c++ development tools)

I should have noted that for the older versions of eclipse i used the matching older versions (former "mcu eclipse" ilg....) of the plugins.

The issue is the missing dependency to C/C++ Development tools, as I wrote in my post before closing the issue:

Hah, I got it. Could you please add a dependency to the following two packages?

C/C++ Development Tools 10.1.0.202012020953 org.eclipse.cdt.feature.group Eclipse CDT
C/C++ GDB Hardware Debugging 10.1.0.202011291939 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT

Without the Development Tools eclipse can compile correctly, but cannot find gdb for some reason (albeit it is in the same directory as g++ or gcc). If you trick it via PATH to find gdb it does not start openocd correctly.

This is the minimal package list for a minimal embedded c/c++ eclipse:

C/C++ Development Tools 10.1.0.202012020953 org.eclipse.cdt.feature.group Eclipse CDT
C/C++ GDB Hardware Debugging 10.1.0.202011291939 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT
Eclipse Platform 4.18.0.I20201202-1800 org.eclipse.platform.ide Eclipse.org
Embedded C/C++ Arm Cross Compiler 6.0.0.202012080907 org.eclipse.embedcdt.managedbuild.cross.arm.feature.group Eclipse Embedded CDT
Embedded C/C++ Core 6.0.0.202012080907 org.eclipse.embedcdt.feature.group Eclipse Embedded CDT
Embedded C/C++ OpenOCD Debugging 6.0.0.202012080907 org.eclipse.embedcdt.debug.gdbjtag.openocd.feature.group Eclipse Embedded CDT

And Looking back at my opening post the c/c++ development tools were missing there too.

Besides that I woke up in times when you installed your OS from diskettes and I hate to download a ton of megabytes, install it, already knowing that i dont need it. So i start a barebone platform and install only the plugins i need. Especially working in teams with multiple languages like python, php and c makes managing and distributing the development environment easier. Since only one folder (besides the binaries like gcc) need to be copied.

[ilg-ul]

I don't understand your use case, and generally I don't recommend mixing plug-ins from different sources, thus the safest way is to use separate Eclipses for different languages, but it is up to you to decide your configuration.

If you think that you identified a problem of missing dependencies, can you provide a detailed sequence of steps for us to reproduce?

[dhMat]

Hallo,

I have also stumbled over the openOCD problem with quotes and also found this old issue #12

After a lot of try and error I have found a solution:

TL;DR shared configuration file with linux line ending works, configuration file with windows line endings end with error Unexpected command line argument: Started by GNU MCU Eclipse.

I am working with eclipse on Windows and the starting situation was, that I was continueing work on an existing project. When I tried to debug with openOCD the debug session ends with the error

xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-09-01-17:58)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Unexpected command line argument: Started by GNU MCU Eclipse

I was wondering what the problem is, because I have another project with working debug configuration. So to make sure that some hidden configuration is not the problem, I had created a new debug configuration. Set all needed configuration values as used in the working debug configuration. But still the problem persists.

I had started testing starting openOCD from command line and the problem happen there also. When running openOCD with ... -c 'echo "Started by GNU MCU Eclipse"' also the same error message occur, as when run in eclipse. After multiple test I choose to test with escaping the double quotes and this is working: ... -c "echo \"Started by GNU MCU Eclipse\""

So it seems single quotes are not supported by windows command line (cmd). But I have found no way to change how the echo command is appended by the eclipse plugin. So why the other project is working???

Both projects are using shared files for debug configuration and so I have compared both. The diff program shows that only the project names differ AND the line ending. After changing the line ending of the debug configuration file both debug configurations are working 😃

So it seems when creating a new debug configuration on windows eclipse is creating a configuration with windows line ending (independant if shared or local file is used), but the plugin is only working with linux line endings.

Hope this helps and you can get rid of your problem, too.

Edit It seems after the debug configuration is working, also changing the line ending back to windows \r\n does not trigger the issue. So it seems the issue occur only when creating or improting the debug configuration the first time.

[TommyMurphyTM1234]

So it seems single quotes are not supported by windows command line (cmd).

I thought that the recommendation was that the xPack Windows Build Tools be used in this context in which case the BusyBox implementation of sh would be used instead of the Windows Command Shell cmd, and this would probably eliminate the problem that you're experiencing?

• https://xpack.github.io/dev-tools/windows-build-tools/

[dhMat]

The command line is only relevant for testing outside of Eclipse. I think the problem is caused by the openOCD plugin which is using no shell. At least if I understand the discussion around this topic correctly.

[ilg-ul]

@dhMat, if you think that you identified a bug, please provide a clear procedure to reproduce it.

[dhMat]

I did not manage to reproduce the problem.

After fixing the problem by changing the line endings in the shared debug configuration file. Also importing the old project no longer trigger the bug.

I do not know what the difference between was when the problem occured and now

[TommyMurphyTM1234]

The command line is only relevant for testing outside of Eclipse.

I don't really understand what you're saying here.

I think the problem is caused by the openOCD plugin which is using no shell.

The plugin will use the xPack Windows Build Tools BusyBox sh if things are configured as I believe is recommended on Windows.

[TommyMurphyTM1234]

• https://xpack.github.io/dev-tools/windows-build-tools/#benefits

For those interested in technical details, if make does not find a sh in the path, it falls back to using the Microsoft cmd.exe when launching sub-processes. As with other Windows implementations, compared to Unix shells, cmd.exe is severely restricted, also impacting the make correct behaviour.

I suspect that the same applies to the Eclipse plugin launching OpenOCD.