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?

[oBFusCATed]

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

Cannot compute
Can you explain what you had in mind with this sentence?

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

I installed Code::Blocks on Windows with the bundled MinGW and saw that it includes gdbserver.  So, I replicated the test above (gdbserver and gdb on the same machine) on Windows and the process pausing with the stop button problem occurs.  Code::Blocks says "Trying to pause running process..." and the process doesn't pause.

So, both problems can be replicated using only 1 machine.  You don't need an embedded target just a remote target.

[oBFusCATed]

Great, I'll see what I can do to fix them:)

[pfong]

It seems the debugger pausing problem has been discussed before. See: http://forums.codeblocks.org/index.php?topic=8577.0

[pfong]

Would it be better if I put the information that I find in the bugs or here or both?

I did some more research on the break problem.  It seems that in Windows you can send a SIGINT with the WM_CHAR message (See http://msdn.microsoft.com/en-us/library/ms811896#ucmgch09_topic3).  Unfortunately, the documentation here is not detailed and I have not been able to get this to work.  I made a program that uses SendMessage to send messages indicating Ctrl is pressed and then C but it doesn't seem to do any thing.  I haven't even been able to use it to press keys in Notepad and get characters to appear.

[oBFusCATed]

I think, I've gathered enough info, just need to do some testing + implementation.

I'll see if I can find some time this weekend...

[MortenMacFly]

Great, I'll see what I can do to fix them:)

You are the first person I know saying "Great" if a bug is found. :lol: :lol: :lol:

[oBFusCATed]

You are the first person I know saying "Great" if a bug is found. :lol: :lol: :lol:

I say "Great", when I know how to reproduce a bug, because most of the work is done at this time.

[oBFusCATed]

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.

This does not happen in my tests. C::B sends the correct continue command, when I'm remote debugging.
I've tested on windows and linux, both worked.
I've tested with CB from the debuggers branch.

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

The stop but happens for me too...

Edit: If you can't fix the continue/run problem please provide simple example project, please setup it to connect to localhost:1234 and specify all steps required to reproduce the problem...

[pfong]

This does not happen in my tests. C::B sends the correct continue command, when I'm remote debugging.
I've tested on windows and linux, both worked.
I've tested with CB from the debuggers branch.

Edit: If you can't fix the continue/run problem please provide simple example project, please setup it to connect to localhost:1234 and specify all steps required to reproduce the problem...

I've attached a simple helloworld project.  I am testing with Code::Blocks 10.05 on Windows.  This is the behavior that I observe...
Situation 1:
Make sure "Do *not* run debugee" is checked off (enabled).  In one window in the helloworld directory run "gdbserver :1234 bin\Debug\helloworld.exe".  In Code::Blocks press the "run/continue" button.  You will see the gdbserver report "Remote debugging from host 127.0.0.1".  If you press "run/continue" again, it will send "run" to gdb.  This causes the gdbserver say "Killing inferior" and exit.  The local gdb runs the process locally and a console window pops up.
Situation 2:
Make sure "Do *not* run debugee" is NOT checked off (enabled).  In one window in the helloworld directory run "gdbserver :1234 bin\Debug\helloworld.exe".  In Code::Blocks press the "run/continue" button.  You will see the gdbserver report "Remote debugging from host 127.0.0.1".  Then "Hello world!" is printed out in the window with gdbserver and it waits in the while (1) loop.

The behavior in situation 1 is broken.  It should send "continue" when you press the "run/continue" so that the process runs where gdbserver is running just like in situation 2.

The workaround I've been using is to use
"define run
     continue
end"
in the GDB initialization to redefine run to be the same as continue.

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

The stop but happens for me too...

Are you saying it works correctly (stops the program) or that it is broken (prints out "Trying to pause running process..." and nothing happens)?

[oBFusCATed]

I've attached a simple helloworld project.  I am testing with Code::Blocks 10.05 on Windows.  This is the behavior that I observe...
Situation 1:
Make sure "Do *not* run debugee" is checked off (enabled).  In one window in the helloworld directory run "gdbserver :1234 bin\Debug\helloworld.exe".  In Code::Blocks press the "run/continue" button.  You will see the gdbserver report "Remote debugging from host 127.0.0.1".  If you press "run/continue" again, it will send "run" to gdb.  This causes the gdbserver say "Killing inferior" and exit.  The local gdb runs the process locally and a console window pops up.
Situation 2:
Make sure "Do *not* run debugee" is NOT checked off (enabled).  In one window in the helloworld directory run "gdbserver :1234 bin\Debug\helloworld.exe".  In Code::Blocks press the "run/continue" button.  You will see the gdbserver report "Remote debugging from host 127.0.0.1".  Then "Hello world!" is printed out in the window with gdbserver and it waits in the while (1) loop.

The behavior in situation 1 is broken.  It should send "continue" when you press the "run/continue" so that the process runs where gdbserver is running just like in situation 2.

Thanks will test tonight...

The stop but happens for me too...

"but" should have been "bug", sorry for the typo.
And yes, the bug is present on my machine.
And also it will be very hard to solve, probably impossible
or at least will require replacing wxProcess with something else (or patching wxProcess).
I'm still testing and do not have a final opinion on the matter.

[oBFusCATed]

The "run/continue" bug should be fixed with this patch: http://forums.codeblocks.org/index.php/topic,10908.msg88984.html#msg88984

[oBFusCATed]

The interrupting bug should be fixed with this patch: http://forums.codeblocks.org/index.php/topic,10908.msg89081.html#msg89081

[pfong]

Nice work.  I have not had time to try a build of the debugger branch yet though.  I've been using Code::Blocks on Ubuntu instead.

Should we update the bugs in the bug tracker 017441 and 017451?  I'm not familiar with the Berilos bug tracker and don't see how to update the status.

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.

[oBFusCATed]

Should we update the bugs in the bug tracker 017441 and 017451?  I'm not familiar with the Berilos bug tracker and don't see how to update the status.

I think only the devs/admins can do that (also there are some duplicates).
But first verify that the bugs are fixed in your environment....

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 not, but will look at it some day:)

[oBFusCATed]

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:

Code

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

[pfong]

I saw this problem on Ubuntu.
I tried to define a function in the "Additional GDB Commands -> Before Connection".  For example for OpenOCD:
define reload
        monitor jtag_khz 500
        monitor reset init
        monitor jtag_khx 10000
        load
end

The function would not be defined in GDB.
It worked fine if I put the same thing in the global compiler/debugger settings under "Settings"->"Compiler/Debugger"->"Debugger settings"->"Debugger initialization commands"

[oBFusCATed]

pfong: have you checked if the previous two bugs are fixed in the latest revisions?

[pfong]

I did a quick test with the nightly on Sept 19 SVN 6608 debugger branch on Windows.
When do not run debugee is checked, C::B now correctly sends "cont" instead of "run" the first time you press run/continues.
Breaking while the target is running seems to work fine as well.

However, I did notice that it did not seem to handle next or step correctly.  I had stopped at a while(1) loop in my target.  When I pressed next or step in the toolbar it would send next or step to GDB but did not realize when GDB returned (the command input box was not re-enabled).  It did work correctly when I typed next or step into the command box though.

[oBFusCATed]

Can you provide the debug log?
Also does it work in normal console app debug session?

[pfong]

Ok, I did a little more experimenting with a regular native console app.
Next never returns control in GBD on a while(1) loop.  This seems correct because you never get to the next line.
So the C::B behavior when you press "Next" is correct.  The UI goes into the running state and you can break by pressing the break button.
The behavior when you execute next by typing it in the command box is incorrect or at least undesirable.  The UI does not go into the running state, so you cannot break by pressing the break button (or any other way as far as I can tell).

In both cases the only thing I see in the debugger log is "next".