#42 "GDB OpenOCD Debugger > Start OpenOCD locally" not working in my environment
Hi,
When using the the "GDB OpenOCD Debugger" launch, I can't get the "Start OpenOCD locally" option to work. After a short time of launching I received an error in final launch sequence:
localhost:3333: The system tried to join a drive to a directory on a joined drive.
However, I am able to successfully launch the debug session if I start the openocd server manually, using the same command line that Eclipse issues when the "Start OpenOCD locally" option is selected,ie
D:\openocd\bin>openocd.exe -c gdb_port 3333 -c telnet_port 4444 -f openocd.cfg
I've run this in an Eclipse SDK with a self hosted runtime workbench.
In the method
ilg.gnuarmeclipse.debug.gdbjtag.openocd.Backend.GdbServerStep
the call to launch openocd:
fServerProcess = launchGDBProcess(commandLineArray);
appears to succeed, but the target-select remote localhost:3333 command fails.
Below you can see the versions of stuff I'm using. Any ideas on why the openocd spawn isn't working in my environment?
cheers john
<dsf trace="" attached="">
Versions:
ilg.gnuarmeclipse.debug.gdbjtag.openocd: 1.1.1 (latest from git)
openocd.exe --version
Open On-Chip Debugger 0.8.0-dev-00328-g0b26376 (2014-02-23-19:04)
gdb: gnu gdb 7.6
eclipse/cdt: kepler SR1
host: windows 8.0
from your log I see:
'The system tried to join a drive to a directory on a joined drive'
which I could not find in the CDT source tree, might be an answer from OpenOCD.
did you also try with the stable 0.7?
on my Mac I had no problems with OpenOCD 0.7.
any progress with this?
Hi,
yes I've found the problem thanks. It was more an issue with my usage of openocd; specifically a path issue.
For the failing case In the GDB OpenOCD Debugging > Debugger > "Other options" field I had:
"-f openocd.cfg"
(where openocd.cfg is located in D:\openocd\somn-openocd-20140223\bin)
And the Executable is:
"D:\openocd\somn-openocd-20140223\bin\openocd.exe"
When I used an absolute path in the "Other options" field, eg
"-f D:\openocd\somn-openocd-20140223\bin\openocd.cfg"
it worked.
I'm a little confused as to what openocd is using as its working directory. Perhaps an enhancement could be to add a "Working directory" field to the Debugger LCD tab, like the C/C++ Application>Arguments tab has.
Incidentally the error message:
'The system tried to join a drive to a directory on a joined drive'
is from the Windows USB system I think.
Best rgds john
yes, this is a known problem with openocd.
the location of the working directory is configured at build time and is platform dependent. you should find it on your computer, it contains lots of configuration files, and this is the place where it is recommended to store your configuration files.
it is not very portable to add absolute paths to configuration files, if really necessary this should be done in two steps, with a global variable and a new interface field.
but this becomes complicated. the easiest solution is to store your files in the existing configuration folder.
Hi,
I was referring to the working directory in the context of the following:
[OpenOCD User’s Guide, Section 4 Running]
"Configuration files and scripts are searched for in
1. the current directory,
2. any search dir specified on the command line using the ‘-s’ option,
3. any search dir specified using the add_script_search_dir command,
"
When I run openocd on the command line I expect the working directory it uses is the directory you are in when openocd is launched. But with Eclipse I'm not sure where that is; is it the installation directory of eclipse, or the location of the C/C++ project you're working with, or ...? My suggestion is to have a new text field, with a browse and variables button etc, to specify this type of working directory. Maybe it could be populated with a default path, perhaps the path of the openocd executable.
I agree about having absolute paths, but I'm struggling to specify a relative one because I don't know where its relative to.
cheers john
I made a change and the plug-in starts openocd in the project folder. it is functional on my Mac, but did not test it on Windows. could you test it?
I considered this, but the default is very platform dependent, and, as I mentioned, it is set at openocd build, so it can be anywhere.
but you can get the same effect by using -s/--search in the current interface.
relative ones should normally use macros. now they can also be relative to the project folder.
as always for beta versions, the new one is available from updates-test
Great! I'll give it a go and get back to you (probably tomorrow now).
cheers john
Hi Liviu,
I just had some time and came to try this but I can't find the change in http://gnuarmeclipse.sourceforge.net/updates-test. Am I too late? Did you remove it?
I think the problem has been sorted out for me. The underlying openocd tool has now been modified to put some smarts into it to find its configuration scripts (I think you alluded to this before) so having the facility inside the GUI is less important now.
cheers john
no. how did you test it?
the change is internal, when the openocd process is started, the current folder is set to the project folder.
so you should be able to use "-f openocd.cfg" if the file is present in the project, without having to use -s/--search.
you mean you use a patched openocd? well, it is ok, but if you do it only to compensate a missing feature in the plug-in, I don't think it is worth the extra maintenance effort.
My mistake; I tried installing the update again (http://gnuarmeclipse.sourceforge.net/updates-test) into a fresh eclipse installation and I see it now.
To test I ...
1) created the file openocd.cfg in the root of my eclipse project the contents of which are:
interface cmsis-dap
source [find target/kl25.cfg]
2) Create a launch configuration "GDB OpenOCD Debugger" with "OpenOCD Setup.Other options" set to:
-f openocd.cfg
3) Also in log file field add:
openocd.log
When I Debug the launch is successful! I also see the log file created in the root of the project.
Thanks, john
if this works on windows too, then I'll apply the same patch to launching the jlink server and the gdb client.
is there anything else related to this ticket to be done? or we can close it?
Hi,
Yes, my test platform was Windows 8.
Great.
Nothing else from my side
cheers john
Last edit: John Moule 2014-03-14
ok, thank you, will be closed after releasing the next version
the same patch was applied to launching all debugging processes for jlink and openocd, so it should be possible to refer to files located in the project folder without any path.
the beta version is available on updates-test.
I would also appreciate your comments on the new structure of the projects generated by the plug-in:
https://sourceforge.net/p/gnuarmeclipse/beta-versions/
I had this exact problem earlier today. I did try putting an absolute path to the board configuration file into the options box just as John did. This did not solve my problem, still go the error message about localhost:3333 trying to join a drive or directory on a joined drive.
I ended up physically disconnection and reconnecting my St-Link/V2. From then on I was able to debug again for a few times until it happened again.
I did run into issues with my St-Link/V2 occasionally locking up somehow before using this plugin. Disconnecting and reconnecting always made it work again for some time. I have the suspicion that the St-Link/V2 gets upset sometimes when the target power gets interrupted.
I will try and install the new beta-version tomorrow and see how it will work.
my setup is Windows 7/64 running Kepler
Last edit: Peter Hofmann 2014-03-26
Hi Liviu,
I'll checkout the beta-version. But just in the middle of a release so I hope to be able to get to it towards the end of next week.
"...new structure of the projects generated by the plug-in" sounds intriguing. Can you summarise what's changed?
cheers john
in other words, the templates are completely different
Thanks for the summary. I haven't any experience of using your templates so far, but will take a look next week.
cheers john
fixed in 2.2.1-201404120702