OpenOCD Issue

[sidprice]

I have a project I am trying to get started with debugging. The debug pod is an STLinkV2 and the target is a Nucleo-F401RE. My project builds correctly and when I start debugging GDBServer looks good:

Open On-Chip Debugger 0.9.0 (2016-10-14) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v23 API v2 SWIM v9 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.239293
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
stm32f4x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 0x489fc31e msp: 0x0000000c
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
VisualGDB_OpenOCD_Ready

However, GDB fails to connect to the target:

VisualGDB is licensed to Sid Price
C:\SysGCC\arm-eabi\bin\arm-eabi-gdb.exe –interpreter mi C:\DataRoot\Projects\bmp_windows_build\bmp_windows_build\VisualGDB\Release\app.elf
-gdb-version
=thread-group-added,id=”i1″
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=i686-pc-mingw32 –target=arm-eabi”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/&gt;.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from C:\DataRoot\Projects\bmp_windows_build\bmp_windows_build\VisualGDB\Release\app.elf…
done.
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=i686-pc-mingw32 –target=arm-eabi”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/&gt;.
For help, type “help”.
Type “apropos word” to search for commands related to “word”.
OK
-list-features
^done,features=[“frozen-varobjs”,”pending-breakpoints”,”thread-info”,”data-read-memory-bytes”,”breakpoint-notifications”,”ada-task-info”,”language-option”,”info-gdb-mi-command”,”undefined-command-error-code”,”exec-run-start-option”]
-gdb-set disassembly-flavor intel
No symbol “disassembly” in current context.
-gdb-set print demangle off
OK
-break-insert -f main
^done,bkpt={number=”1″,type=”breakpoint”,disp=”keep”,enabled=”y”,addr=”0x080014c8″,func=”main”,file=”main.c”,fullname=”C:\\DataRoot\\Projects\\bmp_windows_build\\bmp_windows_build\\bmp_windows_build\\main.c”,line=”35″,thread-groups=[“i1″],times=”0″,original-location=”main”}
set remotetimeout 60
&”set remotetimeout 60\n”
=cmd-param-changed,param=”remotetimeout”,value=”60″
OK
target remote :50048
&”target remote :50048\n”
&”:50048: No connection could be made because the target machine actively refused it.\n”
:50048: No connection could be made because the target machine actively refused it.
r7: Failed to connect to the debug stub
at l61.r(String a, g5 b)
at l61.y(IEnumerable`1 b, Boolean a)
at l61.i_2(DebugCustomizationSettings a)
at jb.h3()
at VisualGDB.GDBDebugEngine.o2(ry b, d a)

Please advise how I can correct this,

Sid

• This topic was modified 7 years, 12 months ago by sidprice.

[support]

Hi,

Looks like a firewall or antivirus might be blocking the connection between gdb and OpenOCD.

Please try disabling it. If it does not help, please enable the diagnostic logging via View->Other Windows->VisualGDB Diagnostics Console and check if the gdb_port specified in OpenOCD command line matches the port used in the ‘target remote’ command.

[sidprice]

In the GDBSession view I see:

&”target remote :49321\n”
&”:49321: No connection could be made because the target machine actively refused it.\n”
^error,msg=”:49321: No connection could be made because the target machine actively refused it.”

In the VisualGDB diagnostics I see:

Launching gdbserver: C:\Users\Sid\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg -c “gdb_port 49321” -c “telnet_port 49320” -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”

There is no firewall enabled and Windows Defender “realtime protection” is turned off.

Sid

[support]

Hi,

Thanks for checking this. Both OpenOCD and gdb settings look correct, so it looks like some system component is preventing them from being connected. Normally OpenOCD should connect to the hardware and open a TCP port (49321 based on your log) allowing gdb to connect to it and get access to the hardware. However, despite the correct setting and matching ports, something is interfering with the connection.

To diagnose this further, please try running the OpenOCD command shown in the log from the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\share\openocd\scripts directory. Once OpenOCD is running, start a new instance of arm-eabi-gdb.exe and type “target remote :49321” there.

If the problem reproduces, please try pinpointing it via the following steps:

1. Instead of launching arm-eabi-gdb.exe and typing “target remote :49321”, please try running “telnet localhost 49321” (you may need to install telnet via Add/Remove Programs -> Windows Components). If this works, please try a different gdb binary.
2. Alternatively please try changing the port to something below 10000 (e.g. 1234 instead of 49321).
3. If none of the steps above help, please launch OpenOCD so that it opens the port 49321 and then run “netstat -a -b -n > list.txt” from an elevated command prompt and see if the output mentions OpenOCD listening on port 49321.

[sidprice]

After starting OpenOCD with the command from the log I started arm-eabi-gdb and typed “target remote:49321”, the response was:
C:\SysGCC\arm-eabi\bin>arm-eabi-gdb.exe
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=i686-pc-mingw32 –target=arm-eabi”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/&gt;.
For help, type “help”.
Type “apropos word” to search for commands related to “word”.
(gdb) target remote:49321
Remote debugging using :49321
warning: No executable has been specified and target does not support
determining executable automatically. Try using the “file” command.
0xfffffffe in ?? ()
(gdb)

[support]

Hi,

Thanks for checking this, looks like the problem might be caused by the port auto-detection mechanism used by VisualGDB. Please try editing your .vgdbsettings file as follows:

    <DebugMethodID>com.sysprogs.arm.openocd</DebugMethodID>
    <DebugMethodProperties>
      <Entries>
        <...>
        <KeyValue>
          <Key>com.sysprogs.arm.openocd.gdb_port</Key>
          <Value>1234</Value>
        </KeyValue>
      </Entries>

This should force VisualGDB to use the port 1234 for connection between OpenOCD and gdb. If this solves the problem, please check if port 49321  would also work when specified manually. If yes, it can be some weird conflict between VisualGDB opening and immediately closing the port to test it and OpenOCD using it to accept connections. If you can confirm this, we will add a workaround to our OpenOCD package.

[sidprice]

THis gives the same result, the connection fails. The gdb_port added manually is being used when starting OpenOCD:

Launching gdbserver: C:\Users\Sid\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg -c “gdb_port 1234” -c “telnet_port 49862” -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”

[support]

Hi,

Thanks for confirming this. When VisualGDB displays a message about connection failure, does it offer a ‘retry’ option? If yes, does it work? If no, are you using the latest v5.2?

[sidprice]

YES!!! Using retry the connection is good and the target stops at start of main.

[sidprice]

Is this a clue … Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1219). Workaround: increase “set remotetimeout” in GDB

[support]

Hi,

The remotetimeout should not affect the initial connection problems.

Could you try locating the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\edp.xml file and increasing GDBServerDelay to 5000 or even more? Perhaps OpenOCD initialization takes longer than the 2 seconds that VisualGDB waits normally?

[sidprice]

With GDBServerDelay set to 5000 VisualGDB starts correctly.

However, it operates VERY slowly. A view opens saying the “Load” is taking too long and then if I try to step a line it tales 3-4 seconds to complete, this seems very slow.

Sid

[support]

Hi,

Are you using a VM with USB virtualization? If yes, slow debugging is to be expected. Please try running VisualGDB directly to get the best performance.

[sidprice]

Yes I am running in a VM, I have another debugger that uses STLinkV2 and it does not have this speed issue! I cannot run the tools on the host PC because clients require delivery of software in a VM.

• This reply was modified 7 years, 12 months ago by sidprice.

[support]

Hi,

Sorry, perhaps the other debugger is handling some USB requests differently. VisualGDB relies on OpenOCD to handle low-level debugging and we can confirm that it does not work very fast on VMs. Hence our best advice is to use a physical VM instead (or at least run OpenOCD on a physical machine, however that would require a complex manual setup).

[Author]

Posts