Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Level 3
Level 3
10 replies posted 5 replies posted 10 questions asked

Im using the BCM943362WCD4 (rev P200) on a BCM9WCD1EVAL1 board, rev P100. My host is a Mac. The debugger uses the FTDI USB-serial converter on the EVAL1 board. I follow the QSG instructions to debug an app on the device, and it all works, up to section 4.3, step 8: "To stop debugging, click the square red stop button in the Debug tab". I do this, and perhaps debugging stops, but I cant build, run and debug my app again. The IDE hangs, and I have to force quit it.

Is there some magic sequence of operations I have to make in order to go through the build/run/debug cycle without force-quitting Eclipse?

10 Replies
50 sign-ins 25 sign-ins 25 comments on KBA

Is this an issue with new SDK?


Running into the same issue here.

What's considered new? I'm running 2.4.1 - I know there may be a 3.0.0 (even 3.0.1) somewhere, but I have a hard time finding it.


I've sent invites.


Unfortunately, still an issue for 3.1.0; steps to reproduce is the same as OP

Not applicable

What system/OS are you running on?

Is this issue 100% reproducible?

When the hang happens - can you go to the appropriate task manager and see if the fdti openocd application is still running or not?

We cannot reproduce this at this moment. So need more information from people who can.


osx 10.9.5 running on a early 2011, 13" mbp

The process 'openocd-all-bcrm-libftdi_run' starts when running debug in eclipse, and stops when terminating the debug session.

I will try this on a different machine running osx and report back.


Hi All,

I was able to reproduce the same, and I realised its a bug in Eclipse

Bug 427410 – Eclipse debugger hangs on terminate with Mac OS X and JRE7



Hey Vik,

Were you able to reproduce this issue using their instructions?

Here were my steps:

  • Change jdk to 1.6 and run WICED debug on our application; hangs on terminate
  • Open a new hello world project, debug according to their instructions using gdb (/usr/local/bin/gdb); debugs and terminates correctly
  • Run WICED debug on our application; hangs on terminate
  • Run WICED debug on snippets; hangs on terminate

GDB traces output:

WICED IDE (Helios)

503,707 19-gdb-exit

504,053 19^exit

504,232 =thread-group-exited,id="i1"

Eclipse (Kepler)

601,197 31-interpreter-exec --thread-group i1 console kill

601,198 ~"Kill the program being debugged? (y or n) [answered Y; input not from terminal]\n"

601,200 =thread-group-exited,id="i1"

601,200 31^done

601,246 32-gdb-exit

601,247 32^exit

601,247 33-break-delete --thread-group i1 2

601,247 34-break-delete --thread-group i1 3

601,247 35-break-delete --thread-group i1 1

601,247 36-break-delete --thread-group i1 4

I can detach the gdb process by issuing 'detach' from the gdb console. Quitting gdb from the console seems to produce the same results.

It feels like Helios isn't aware when gdb quits, and hangs from there. Perhaps Eclipse has fixed this at some point.

Side note, the IDE bundled with WICED 2.4.1 OSX install has a couple of local references under

Eclipse preferences --> Install/Update --> Available Software Sites

lock attach
Attachments are accessible only for community members.
Level 3
Level 3
5 likes given First like received First like given

Found a temporary workaround that's much better than force closing

At any point you'd like to terminate, do the following:

  1. Bring up the gdb console in WICED IDE (you may need to switch console tabs)
  2. Disconnect the remove device by entering 'disconnect' followed by an 'enter'
  3. Terminate last_built.elf first (right click --> terminate, or left click to select, then click terminate)
  4. Terminate gdb afterwards (right click --> terminate, or left click to select, then click terminate)
    • must be done in this order


     Selecting and terminating last_built.elf also seems to work.

Level 5
Level 5
50 replies posted 25 replies posted 10 replies posted

I am finding exactly the same issue (Yosemite, SDK 2.4.1 - as I am using an STM32F1xx in an SN8200x).

The work-around seems to work but a fix would be appreciated.