cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

StSm_298421
New Contributor II

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?

0 Likes
10 Replies
GregG_16
Employee

Is this an issue with new SDK?

0 Likes
CaWo_1798781
New Contributor II

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.

0 Likes
GregG_16
Employee

I've sent invites.

0 Likes
CaWo_1798781
New Contributor II

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

0 Likes
Anonymous
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.

0 Likes
CaWo_1798781
New Contributor II

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.

0 Likes
VikramR_26
Employee

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

thnx

vik86

CaWo_1798781
New Contributor II

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

0 Likes
CaWo_1798781
New Contributor II

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

Edit:

     Selecting and terminating last_built.elf also seems to work.

SuMa_296631
Contributor II

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.

Susan

0 Likes