I tried the Eclipse IDE again, together with the our mspgcc tools.

i used Eclipse 2.1.2 + CDK 1.2, msp430-gdb 6.0, latest msp430-gdbproxy (guess the older one works just fine too)

some notes:

you have to change the file:
  plugins/org.eclipse.cdt.debug.mi.core_1.2.0/plugin.xml
all the cpu="native" lines to
  cpu="native,msp430"

write a gdb.ini or .gdbinit file for your project
"""
ta re :3333
set remoteaddresssize 64
set remotetimeout 999999
mon erase
load aout.elf
"""
or if you want to play with the simulator:
"""
target sim
load aout.elf
"""

then to run the debugger select "debug ...", create a new "c/c++ local" configuration, use msp430-gdb as the debugger, specify the gdbini file from above. i'm using the "Cygwin GDB Debugger" type on Win32. The "C/C++ Application" field has to be some file, but it does not matter as we download in the gdbini.

what worked so far:
download and execute an msp430 app, setting and running to breakpoints, reading registers and flash/variables. single stepping worked too, altough it could be faster (single stepping is always a bit slower with the msp430 as the stepping is done via jtag)

i'd think that "step return" should step out of the current function, that did not work in my test, but setting a breakpoint after the function and "resuming" did the trick.

i still get "msp430-gdbproxy.exe: timeout while reading from GDB", not sure why, the timeouts should be large enough.. it does not seem to be a big problem either, as the debugging works fine otherwise. (altough it could be the reason for a slow down) the simulator is much faster, thus i think that the slow down comes from the communication overhead from eclipse<->gdb<->gdbproxy<->JTAG, especialy with the JTAG beeing the slowest part in the chain...

with the register, variable and memory views it gets even slower when single stepping, as it uploads the values each time... disabling "auto refresh" of these is a good idea (can be done with the icon in the toolbar in the respective windows, variables can be disabled each on its own).

chris



Reply via email to