cortex-debug: `v.0.2.4` Now Produces "Failed to launch OpenOCD GDB Server: Timeout"...

hi there 👋

this morning i started hitting the following error while attempting to debug:

Screen Shot 2019-05-13 at 11 49 38 AM

Failed to launch OpenOCD GDB Server: Timeout

i don’t see anything interesting in the developer tools console. the adapter output is:

Open On-Chip Debugger 0.10.0 (2019-01-29-17:30)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.10
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : reduce speed request: 10000kHz to 5000kHz maximum
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints

but nothing seems out of order there 🤷‍♂

as of v0.2.3, this was working fine. i see v0.2.4 was released a few hours ago. if i use VSCode’s “Install Another Version…” option to revert back to v0.2.3, debugging works again for me.

i’ll try to update this issue w/ more technical detail as i find it 👍

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 5
Comments: 31 (9 by maintainers)

Most upvoted comments

@adammunich - if you don’t want to upgrade your OpenOCD you should be able to now configure a regex through the overrideGDBServerStartedRegex launch.json parameter - something along the lines of "overrideGDBServerStartedRegex": "Info\\s:\\s([^\\n\\.]*)\\.cpu([^\\n]*)" should work (hopefully escaped that all correctly

Marus on Jun 10, 2019

I can confirm that brew install open-ocd --HEAD indeed fixes the problem (macOS). @john-terrell Check that openocd actually runs from the command line and parses the openocd config file without any errors. I had to make a few changes to my openocd.cfg to get it to start up without any errors due to syntax changes (chain position, manual dap creation etc.). Once openocd starts without reporting any errors the plugin works well.

I had to add the following (also a SAM4 board):

transport select swd before the source [find target/swj-dp.tcl] line
dap create XXX -chain-position $_TARGETNAME before the $_TARGETNAME configure line
Replace -chain-position $_TARGETNAME in the configure line to -dap XXX

tn-5 on May 15, 2019

Little update. I emailed the OpenOCD maintainers are Cypress. Yes, most vendors are forking it creating/bundling their own versions. Vendors are also unable to put changes/fixes back into OpenOCD. It takes 6 months to year or more before anyone even looks at a PR and schedule a review. The review process itself can take months once it starts. I looked at their list of issues and PRs and it is not very pretty. Commits are happening at a furious rate (several a day) though, but no releases since approx Jan 22, 2017

And once a vendor forks, and gets the thing working for their device, they rarely go back and pull from the original master, because of the testing overhead. Kinda like the Android situation 😃

I am just trying to explain the state of things at OpenOCD. OpenOCD !== OpenOCD. If you pick stuff from the HEAD, it may or may not work for your chip.

@Marus and I are hopeful that we will find a solution that is a bit more resilient, very soon. See issue #167

haneefdm on May 18, 2019

First, I want to apologize to @Marus and everyone else for screwing up your debugging experience and time. I researched it a bit more.

I don’t understand OpenOCD methodology and how vendors are using it. Seems like vendors are forking some old version and making private releases, custom mods, etc. OpenOCD folks don’t seem very responsive either. Found a serious bug in OpenOCD there and asked for help, provided fix, etc. and zero response. And, not publishing their latest stable to homebrew, apt-get, etc. I could be wrong.

The version number don’t mean a thing either. Every OpenOCD output I saw has the same version but different behavior because of the 26 forks I suspect.

Thing is you may get the latest from OpenOCD but may not have the proper/full implementations from MCU vendors. Aaaaargh.

Again, sorry.

haneefdm on May 15, 2019

i’m building from source - what version of openocd should we be using?

edit: TIL brew install —HEAD installs the latest from the upstream repo (docs)

still, a known good sha would be helpful for posterity

busticated on May 15, 2019