Hi,
I recently started using an MSP430 for a project and have hit a snag or two when trying to debug the code through C::B.
I have Windows 7 64bit, C::B v8.02, MSPGCC and MSPGCC4 (trying to figure out which one works best), an Olimex MSP430P249 prototyping board and a TI MSP-FET430UIF.
I have a simple piece of code that toggles an LED on the proto board. I can compile and link successfully using either MSPGCC or MSPGCC4 through C::B. However, when I try to debug the application something seems to go wrong in the interface between C::B and the debugger.
When I am using MSPGCC I have msp430-gdbproxy running using the command line:
msp430-gdbproxy --port=2000 msp430 COM6
I can connect and debug using msp430-gdb from the command line. The contents of my .gdbinit file are as follows:
target remote localhost:2000
set remoteaddresssize 16
set remotetimeout 999999
set download-write-size 512
set remote memory-write-packet-size 512
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 512
set remote memory-read-packet-size fixed
The way I have the compiler configured in C::B is that the compiler directory is "C:\mspgcc" and the debugger is "msp430-gdb.exe".
In the debugger settings I have the same contents as the .gdbinit file in my "Debugger initialization commands". Display debuggers log and Don not run the debugee are checked.
In the project properties / debugger settings I have selected TCP, localost and port 2000 with no additional commands.
When I use the Debug menu, Start item I can see the initialisation of GDB in the log window and msp430-gdbproxy shows that gdb has connected to it. I then need to issue a user command "continue" to begin executing. The "run" command issued by using the C::B interface does not work and causes the debug session to fail. Is it possible to change the gdb commands that are issued by teh C::B interface (on a per compiler/debugger basis)?
The other problem I have is that once I have issued the "continue" instruction I cannot break into the execution of the code. Under the command line I can press Ctrl-C to break execution but the "Stop debugger" menu item in C::B does nothing to the gdb session and I have to terminate it from the task manager. Again, is this something that can be modified on a per debugger basis?
If I try to use MSPGCC4 then I cannot even get the insight debugger to start from within C::B. When I click on Debug -> Start I get the following in the Debugger output window:
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: C:\Users\dmcminn\Documents\Dev\Firmware\mspgcc4_test\
Adding source dir: C:\Users\dmcminn\Documents\Dev\Firmware\mspgcc4_test\
But insight isn't started and there is nothing in the Debugger (debug) window. msp430-gdbproxy doesn't show anything ashaving connected either. Is it even possible to use C::B with insight?
Any help or information would be appreciated.
Thanks.
Yes, this is the branch...
Should I get similar behaviour (to msp430-gdb) if I use gdb + gdbserver?
So... I've taken a look at the code and this feature seems to be implemented,
but you need (probably) to setup the project/target for remote debugging.
This is done in Project -> Properties -> Debugger -> Remove debugging (you should choose a target or <Project>).
void GDB_driver::Start(bool breakOnEntry)
{
...
// if performing remote debugging, use "continue" command
RemoteDebugging* rd = GetRemoteDebuggingInfo();
bool remoteDebugging = rd && rd->IsOk();
...
// start the process
QueueCommand(new DebuggerCmd(this, remoteDebugging ? _T("continue") : _T("run")));
...
}
This feature should be present in the normal(trunk) version of C::B...
BTW, has any one working on the debugger branch looked at bug 017461 ""Additional GDB Commands -> Before Connection" broken"? I discovered that problem while trying to setup the target board using GDB commands in that setting. The bug report was submitted by my colleague.
I've tried to reproduce this problem, but I couldn't. Is this windows only bug?
Here is the output of the three commands I've added:
>>>>>>cb_gdb:>>>>>>cb_gdb:
> info program
The program being debugged is not being run.
>>>>>>cb_gdb:
> info breakpoint
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> exception throw
>>>>>>cb_gdb:
> info threads