Timeout issue with Openocd about cortex-debug HOT 14 CLOSED

Can you post a copy of all the output that is collected in the “Adapter Output” view in the VSCode output tab - and perhaps the output you get when running OpenOCD with your board.

Also, what operating system, as well as the versions for OpenOCD, VSCode and your OS.

The timeout error would mean that it wasn’t able to detect the the server is running and accepting GDB connections in a reasonable amount of time. Since your configuration looks to be reasonable (assuming all your paths are correct) I expect that some of the output is different (either as a result of your configuration file or OS versions).

I am considering at some point adding support for an externally launched - but the request type actually serves a different purpose (launch will flash/restart the microcontroller while attach should only halt the core without restarting/flashing - so that you can examine the state of a system, for example, if it ended up in an error condition).

from cortex-debug.

Software Versions

The versions should all be the latest

• Operating system: Windows 10 Pro
• GCC Version: 7 2017-q4-major (Cortex-M)
• OpenOCD Version: OpenOCD-20170821
• Visual Studio Code: 1.21.0
• Cortex Debug version: 0.1.16

I've got my setup here if your interested

• https://github.com/grbd/GBD.Dlang.MbedBlinkyTest

I've been experimenting with getting Dlang to work
although in this case I avoided that and just tested with some basic cpp code for blinking an LED

Running OpenOCD from the command line

This is the output I get from running openocd on the command line

OpenOCD Server

First start the openocd server

openocd -f scripts\openocd_configs\usb_boardconf.cfg

The config file usb_boardconf.cfg is:

# ARM CMSIS-DAP compliant adapter
# http://www.keil.com/support/man/docs/dapdebug/
source [find interface/cmsis-dap.cfg]
 
# Add the cpu
source [find target/lpc17xx.cfg]
 
# Set the Speed
adapter_khz 500

# Make the initial connection and halt the board
init
targets
reset halt

Output

Open On-Chip Debugger 0.10.0 (2017-08-21) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 200
cortex_m reset_config sysresetreq
adapter speed: 500 kHz
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : SWD DPIDR 0x2ba01477
Info : lpc17xx.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* lpc17xx.cpu        cortex_m   little lpc17xx.cpu        running
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc

GDB Server

Next starting GDB to connect to the openocd server

arm-none-eabi-gdb.exe --eval-command="target remote localhost:3333"

Output:

GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Remote debugging using localhost:3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x1fff0080 in ?? ()

At this point I can run commands like
monitor resume, monitor halt etc to start and stop the led blinking

from cortex-debug.

Thanks for pointing me towards the "Adapter Output" view, this is what I was looking for before but didn't know the name of it

openocd realtive path to config file

it looks as if the first problem is that it was having issues finding the configuration file for openocd with respect to relative paths

Open On-Chip Debugger 0.10.0 (2017-08-21) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
embedded:startup.tcl:60: Error: Can't find ./scripts/openocd_configs/usb_boardconf.cfg
in procedure 'script' 
at file "embedded:startup.tcl", line 60

It's finding the executable file fine with a relative path

"executable": "./BUILD/LPC1768/GCC_ARM/GBD.Dlang.MbedBlinkyTest.elf",

But for the openocd configuration I had to change it from relative to absolute to get it past that point

./scripts/openocd_configs/usb_boardconf.cfg
# Changed to
D:/SourceControl/GitRepos/GBD.Dlang.MbedBlinkyTest/scripts/openocd_configs/usb_boardconf.cfg
# Edit I also found this works
"${workspaceRoot}/scripts/openocd_configs/usb_boardconf.cfg"

This might just be a case of changing the examples on the site to use ${workspaceRoot} instead of ./ when specifying paths

unable to change server port after init

The next problem seems to be the following in Adapter Output:

Open On-Chip Debugger 0.10.0 (2017-08-21) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 200
cortex_m reset_config sysresetreq
adapter speed: 500 kHz
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : SWD DPIDR 0x2ba01477
Info : lpc17xx.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* lpc17xx.cpu        cortex_m   little lpc17xx.cpu        halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Warn : unable to change server port after init

Debug Console:

Reading symbols from d:\SourceControl\GitRepos\GBD.Dlang.MbedBlinkyTest\BUILD\LPC1768\GCC_ARM\GBD.Dlang.MbedBlinkyTest.elf...
done.
"monitor" command not supported by this target.
"monitor" command not supported by this target.

With the following prompt

Falied to launch GDB: localhost: 50000: No connection could be made because the target machine actively refused it
(from target-select extended-remote localhost:50000)

I tried turning off windows firewall, and trying older versions of openocd but that didn't seem to work

from cortex-debug.

Just to narrow things down a bit
I tried using the vanilla gdb plugin and this seems to work okay

launch.conf

        {
            "name": "Debug (OpenOCD USB) - Attach to GDB",
            "type": "gdb",
            "request": "attach",
            "executable": "${workspaceRoot}/BUILD/LPC1768/GCC_ARM/GBD.Dlang.MbedBlinkyTest.elf",
            "target": ":3333",
            "remote": true,
            "cwd": "${workspaceRoot}",
            "gdbpath": "arm-none-eabi-gdb.exe",
            "autorun": [
                "monitor reset halt",
                "load ${workspaceRoot}/BUILD/LPC1768/GCC_ARM/GBD.Dlang.MbedBlinkyTest.elf"
             ]
        },

But of course I need to launch openocd separately first

openocd -f scripts\openocd_configs\usb_boardconf.cfg

And it's probably lacking a few features specific to the cortex-m processor

from cortex-debug.

I do know OpenOCD can be a little bit strange sometimes with it's pathing for configuration files - so not terribly surprising to me that it was having that issue with not finding the script and you had to specify the full path (fortunately you can use the ${workspaceRoot} variable as you noticed to keep it sort of relative). I'll try to see if I can figure out why OpenOCD isn't properly getting the CWD.

As for the followup issue - I think where you're running into issues is that your OpenOCD configuration file does a number of things that standard OpenOCD files do not do (namely the init, targets and reset halt commands. These are preventing the normal initialization that the extension performs from functioning (for example cannot set a port to use for the GDB server; the extension also takes care of halting, flashing, restarting the CPU at the appropriate times as well). I expect if you remove those last three commands from your OpenOCD configuration that it may work.

from cortex-debug.

okay I tried removing the last 3 lines as you've said.
There's some activity (the green light for the CMSIS-DAP adapter flashes for a bit)
which means ether it's flashing, or running openocd server for a short while

But it then drops out with the below error

Error prompt

Failed to launch GDB: Remote communication error. Target disconnected. Target disconnected.: Success.
(from target-select extended-remote localhost:50000)

Adapter Output

Open On-Chip Debugger 0.10.0 (2017-08-21) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 10 kHz
adapter_nsrst_delay: 200
cortex_m reset_config sysresetreq
adapter speed: 500 kHz
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 500 kHz
Info : SWD DPIDR 0x2ba01477
Info : lpc17xx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/50000
Error: Target not halted
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

Thanks for all your help btw

from cortex-debug.

Edit I now have it working thanks to this link
https://mcuoneclipse.com/2016/04/09/solution-for-openocd-cannot-communicate-target-not-haltet/

The above 3 lines mentioned before are removed
and I just needed to add the below lines to the bottom of the configuration file I was using
this triggers a halt on gdb connecting to openocd
This seems to allow single stepping / debugging the code, woohoo

$_TARGETNAME configure -event gdb-attach {
   halt
}
$_TARGETNAME configure -event gdb-attach {
   reset init
}

from cortex-debug.

Glad you got it figured out. Unfortunately I’m not terribly familiar with OpenOCD, as I mostly use J-Link or the Black Magic Probe myself, but wanted to try to support it as it is fairly popular in the hobbyist community. So I couldn’t give you too much advice with writing your own configuration in a manner that would work, just knew it should be possible - as I was able to use it with about 10 or so of their supplied configuration files across a number of chip manufacturers / boards. Glad you found the right combination and posted the details, as it may help others with similar problems in the future.

You mentioned that you are experimenting with Dlang - at the moment I don’t believe you’ll be able to set breakpoints for D as I haven’t listed it in the accepted languages for VSCode. If you let me know what extension you’re using for D in vscode I can add the laungauge identifier to the allowed breakpoints. That should at least allow you to step through code and set breakpoints in D (although some features such as the disassembly view and the global/static scopes of the variables view may not function properly in D)

from cortex-debug.

I've tried using Dlang with breakpoints and it appears to work already as is.
I'm currently able to breakpoint both cpp and .d files and hit the breakpoints in both at the same time

The D plugins I'm using for VSCode is
https://github.com/Pure-D/code-d (webfreak.code-d and webfreak.dlang-bundle)
This appears to be the more popular one at the moment

from cortex-debug.

Ok - interesting that I don’t have it listed as a language I can accept breakpoints for but it is still allowing it - might be something in the language definition that says breakpoints in D are compatible with ones in C/CPP that causes it to allow it.

from cortex-debug.

Well, the thing is, Rust breakpoints also worked before you explicitly enabled them

from cortex-debug.

Hum, that’s very interesting - strange that the VS Code package.json has a setting for “enableBreakpointsFor” if they will let you set them anyway without the language being listed.

from cortex-debug.

Just read something about it - apparently the breakpoints will be enabled if any debug provider or language provider says that a language should have breakpoints; seems like an odd decision to me that this isn’t dependent on the current debug session provider.

So I guess in this case you have another extension (probably the language definition) that says D/rust should have breakpoints.

from cortex-debug.

I think I noticed with this one which is an older plugin, that breakpoints wern't possible
https://github.com/dlang-vscode/dlang-vscode

But with this one, you could add breakpoints (this one seems to have a lot more downloads)
https://github.com/Pure-D/code-d

from cortex-debug.