Matthias, Thanks for the reply. I tried this, but no change in behavior (the debugger seems to work equally well - or not - with --spy-bi-wire parameter). I have been intermittently successful getting Insight to the point of stepping through an .elf and actually debugging, provided it never disconnects and reconnects to gdbproxy in the process. Smelling a possible hardware issue I tried a couple hail-marys (e.g. varying the capacitance on RST\ between 0 and the 2.2nF max suggested by the datasheet), and a bit on the SBW data line, but no improvement in behavior. Scoping these and the Vcc rail suggest they are relatively clean.
Purely guessing, but it feels like a possibility that Insight is simply trying to reconnect too fast, and the chip (via gdbproxy's required housekeeping between dis- and reconnect) can't keep up. Are there any gdb options (or gdb-insight, etc.) to slow it down? Should I just bite it and embrace command-line gdb proper? Tim Matthias Hartmann-2 wrote: > > I am not using spy-bi-wire, but form reading the output of > msp430-gdbproxy.exe --help msp430 > I would guess, you should add parameter --spy-bi-wire to the call to > msp430-gdbproxy.exe. > > msp430-gdbproxy.exe --debug --port=2000 msp430 --spy-bi-wire USBFET > -- View this message in context: http://www.nabble.com/Connection-failure-during-close-and-re-open-msp430-gdbproxy-by-msp430-insight-tp22129473p22219026.html Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.
