Debugging MSP430 from within C::B

[dmcminn_iwc]

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:

Code

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:

Code

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:

Code

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.

[mariocup]

Hi dmcminn_iwc,

please select the menu Settings->Compiler and debugger. Then select from the drop down list: GNU GCC Compiler for MSP430 and choose the tab: Toolchain executables and check the entry for the Debugger. This should be:
msp430-gdb.exe

[dmcminn_iwc]

Hi mariocup,

In the global compiler settings I have GCC for MSP430 selected and the debugger is msp430-gdb.exe.
That is also the compiler settings for the project I am working on.

However, I realise the problem with the debugger not starting was because I had the project build type set to "Native". When I set it back to "Console" it starts the debugger correctly.

I now have the same problems as before, where the "run/continue" button sends a "run" to gdb instead of "cont" and once the program is running on the target you cannot break into it. Are there any known patches for that?

[dmcminn_iwc]

I've taken the time to look through the C::B source code and I can see that these are not going to be fixed.

For the use of "run" vs "cont", once the application has started, if you click the "Debug / continue" toolbar button so that it issues the "run" command and then send the "cont" command through the "user debug command" menu item the state of the debugger and UI are synchronised and the toolbar can be used as normal.

For the use of Ctrl-C to break into a running process I can see that this is not possible due to the use of wxProcess to run the debugger, and wxProcess does not support sending Ctrl-C to child applications directly.

[cichmen]

Hi,
how do you workaround the missing CTRL-C?

[oBFusCATed]

dmcminn_iwc, cichmen: Can you test the debugger branch?

dmcminn_iwc:
1. You say that the debugging process should start with "cont" not "run"?
Do you have some documentation about that or this is a specific problem of your debugger?
Does "run to cursor" work?

2. Hitting the "stop" ("pause" in the debugger branch) button on the toolbar, should send the windows equivalent to Ctrl-C (SIGINTR on Unix) to the debugger => should pause the debuggee.
Any docs why this doesn't work would be helpful.

Can you provide the debugger's log?
Settings -> Compiler & Debugger -> Debugger -> Display debugger's log

[cichmen]

oBFusCATed: You mean "wxpropgrid_debugger" branch? I could try, but will need some time - I've never compiled CB.

Regarding Run/Continue - it is mentioned here: http://mspgcc.sourceforge.net/manual/x1601.html

[oBFusCATed]

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>).

Code

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...

[cichmen]

Debug branch is not working as expected. When pressing the pause button nothing happens.

Run/Continue in latest nightly build:

When I press Debug / Continue first time, it will not run (see log below). When I press it second time, it works as expected.

Working dir : D:\TEMP\_Programming\Cpokusy\
> set prompt >>>>>>cb_gdb:
Reading symbols from D:\TEMP\_Programming\Cpokusy/bin/Debug/testovaci.elf...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=msp430".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
No symbol "debugevents" in current context.
>>>>>>cb_gdb:
> set new-console on
No symbol "new" in current context.
>>>>>>cb_gdb:
> set disassembly-flavor att
No symbol "disassembly" in current context.
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined.
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source D:\TEMP\_Programming\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory D:/TEMP/_Programming/Cpokusy/
>>>>>>cb_gdb:
> directory D:/TEMP/_Programming/
>>>>>>cb_gdb:
> target remote tcp:127.0.0.1:2000
0x00008000 in _reset_vector__ ()
>>>>>>cb_gdb:
> set remoteaddresssize 64
>>>>>>cb_gdb:
> set remotetimeout 999999
>>>>>>cb_gdb:
> monitor erase main
Erasing target flash - main...
 Erased OK
>>>>>>cb_gdb:
> load
Loading section .text, size 0x84 lma 0x8000
Loading section .vectors, size 0x20 lma 0xffe0
Start address 0x8000, load size 164
Transfer rate: 700 bytes/sec, 32 bytes/write.
>>>>>>cb_gdb:
> break main
Breakpoint 2 at 0x806e: file main.c, line 25.
>>>>>>cb_gdb:
> continue
Breakpoint 2, main () at main.c:25
D:/TEMP/_Programming/Cpokusy/main.c:25:463:beg:0x806e
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
No arguments.
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
No arguments.
>>>>>>cb_gdb:
> run
The "remote" target does not support "run".  Try "help target" or "continue".
>>>>>>cb_gdb:
> cont

[oBFusCATed]

Debug branch is not working as expected. When pressing the pause button nothing happens.

I'm talking with the gdb people, to see what is the correct way to implement this feature

Run/Continue in latest nightly build:

When I press Debug / Continue first time, it will not run (see log below). When I press it second time, it works as expected.

Are you sure that you've setup the remote debugging info needed by C::B (In the project properties)?

[cichmen]

Yes, I'm sure. You can see it in the log: "target remote tcp:127.0.0.1:2000".

[pfong]

Run/Continue in latest nightly build:

When I press Debug / Continue first time, it will not run (see log below). When I press it second time, it works as expected.

Are you sure that you've setup the remote debugging info needed by C::B (In the project properties)?

I'm running into this same problem using a OpenOCD ARM target.  It seems to be related to the "Do *not* run debugee" setting.  If the setting is not checked, your program runs to the first break point and things work as expected.  If the setting is checked, it stops at the first instruction your program image and the first time you press run/continue it sends "run" to GDB which complains.  The second time you press run/continue it sends "continue" and things work as expected.

[pfong]

For the use of "run" vs "cont", once the application has started, if you click the "Debug / continue" toolbar button so that it issues the "run" command and then send the "cont" command through the "user debug command" menu item the state of the debugger and UI are synchronised and the toolbar can be used as normal.

I've made this bug #017441.

For the use of Ctrl-C to break into a running process I can see that this is not possible due to the use of wxProcess to run the debugger, and wxProcess does not support sending Ctrl-C to child applications directly.

I've made this bug #017451.  Unfortunately this makes Code::Blocks unusable as an IDE on Windows for embedded development.

[oBFusCATed]

Do you know if the problem happens for normal remote debugging (PC <-> PC) ?
I don't have any experience with embedded development and I can test or improve the code.
But if the behaviour is the same when the connection is PC<->PC I can.

[pfong]

Do you know if the problem happens for normal remote debugging (PC <-> PC) ?
I don't have any experience with embedded development and I can test or improve the code.
But if the behaviour is the same when the connection is PC<->PC I can.

Yes, the run vs cont problem occurs even when the target is a PC.  I ran "gdbserver :2314 helloworld" in a terminal window and set the remote target in the project to 127.0.0.1:2314.

Are you also asking if the stop button not working depends on it being a remote target?