User forums > Embedded development
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
--- End code ---
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
--- End code ---
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\
--- End code ---
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?
Navigation
[0] Message Index
[#] Next page
Go to full version