That works, bur does not format it in a pretty way, nor does it label it, nor can I pick it from a list.
This information was current as of 2015-05-08: My versions of software:
Linux version 3.4-9-rtai-686-pae (Debian 3.4.55-4linuxcnc) (this is an i386 distribution)
GNU DDD 3.3.12
I have spent years programming the MSP430 in a professional setting where I had great tools. I am no longer in that role, so I have needed to learn how the free tools work with the MSP430. I would like to give a big THANK YOU to TI for supporting msp-gcc. Even though TI has stepped up to the plate, there is a lot of old information floating around on the web and significant confusion on how to use the tools. I am a newbie to the use of gdb. It looks like it would have made my life MUCH better in college had I known about it. I would like to post what I have learned about it so that other's may suffer less than I had to. Since I am eyeball deep in my Shizuoka mill conversion to linuxcnc, the host I am using for this work is built on the i386 based linuxcnc box.
I got a HUGE BENEFIT from following the instructions at http://www.instructables.com/id/Getting-started-with-TIs-MSP430-gcc-and-the-MSP430/
With those instructions I built msp430-gcc. I do not remember having to go retrieve anything special to build it. I DID need to wait until it was done to install the header files where they needed to be, because the directories for them are created by using make install from the msp430-gcc source code.
I did need to install mspdebug
apt-get install mspdebug
I made the mistake of trying to use the generic gdb that comes from the ubuntu distribution to try to talk to mspdebug. When I would try to use gdb I would get the error
Reply contains invalid hex digit 59
Solution? Use msp430-gdb instead.
What does typical workflow look like? I am writing a program called cl.c.
[In one terminal window]
# You can use any editor you want, but I was forced to learn vi forever ago, and I kinda like it...kinda...
# FOR THE LOVE OF ALL THAT IS HOLY DO NOT SKIP THE -gdwarf-2 and -g3 options!!!
# They pass on the information needed to view local variables. I had started to give up on gcc
# until I found http://www.delorie.com/gnu/docs/gdb/gdb_17.html by D.J. Delorie!
# Compile your
/opt/msp430-toolchain/bin/msp430-gcc -mmcu=msp430g2553 -O0 -ggdb -Wa,-ahldn -gdwarf-2 -g3 cl.c
# -mmcu obviously sets the chip you are compiling for
# -O0 removes all code optimization -- Keeps the compiler from unlooping your code, inlining stuff, and other
# optimizations that make the debugger crazy(er)
# -ggdb include gdb debugging symbol information VERY IMPORTANT
# -Wa,-ahldn produces a memory map with the assembly. Can be pretty handy
# -gdwarf-2 includes more symbol information for gdb VERY IMPORTANT
# -g3 includes more symbol information for gdb VERY IMPORTANT
(mspdebug) prog a.out
Bound to port 2000. Now waiting for connection...
[In another terminal window]
(gdb) target remote localhost:2000
(gdb) file a.out
Press Ctrl-C to stop execution.
'n' steps one line of C code at a time.
'stepi' will step one assembly instruction at a time.
I learned that
will bring up the graphical interface (insight) and will actually connect to the target. Trying to do it by just starting insight didn't work for me.
I am still evaluating the use of insight. I think I like ddd better.
USING DDD as your Debugger GUI
apt-get install ddd
apt-get install gnuplot
ddd --debugger /opt/msp430-toolchain/bin/msp430-gdb --gdb#--debugger /opt/msp430-toolchain/bin/msp430-gdb tells ddd to use msp430-gdb instead of regulat gdb
#--gdb tells ddd to use gdb style commands to talk to the debugger.
When ddd starts up, one still needs to go the (gdb) command window within ddd and type
target remote :2000
This assumes you are on the default port and the localhost.
Thus far, I have been pretty impressed with ddd. It has most of the stuff I would expect to be able to see. I am still struggling to figure out how to display the SFR's. For example, right now I add a display for P10UT as
Programming, Erasing, and other stuff without restarting gdb
From within GDB, it is possible to pass commands to mspdebug that it should execute. The one for programming the chip is very handy. These are all issued in gdb, not within mspdebug. In DDD, the gdb console is where you type these.
monitor prog cl.c
#monitor tells gdb
Keeping msp430-gdb listening
With the monitor commands, I don't think it is necessary to keep going back to mspdebug and typing gdb. To keep mspdebug from exiting back to command mode, one can set the option gdb_loop.
opt gdb_loop true
GETTING THE MSP-FET430UIF WORKING
for some reason, when I plugged in my MSP-FET430UIF JTAG adapter to try it out instead of the cute little launchpad, I got an error about not being able to locate the firmware (ti_3410.fw).
This is the guy I am trying to use:
I got a bootleg copy of the firmware from here:
After downloading it, I copied it to my /lib/firmware directory as root
sudo cp ~/Downloads/ti_3410.fw /lib/firmware
I used to have this error:
usb 6-2: ti_download_firmware - firmware not found
Now I get this affirmation that I have done the right thing:
usb 6-2: device firmware changed
COMMAND TO CONNECT VIA JTAG and UIF!
mspdebug -j uif -d /dev/ttyUSB0
Workflow for working with the MSP430F1611 and MSP430-GCC now looks like this:
I created a file call f1611.c
#This is for the olimex MSP430-P1611 board to blink the led slowly
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog
P6DIR = 0x01; // P1.0 as output
P6OUT = 0x01 & a>>15;
Then I compiled with:
/opt/msp430-toolchain/bin/msp430-gcc -mmcu=msp430f1611 -O0 -ggdb -Wa,-ahldn -gdwarf-2 -g3 f1611.c
then I loaded it onto the chip with:
mspdebug -j uif -d /dev/ttyUSB0
(mspdebug) prog a.out
I ran it with:
Ctrl-C interrupts it.
(mspdebug) opt gdb_loop true
in a terminal window:
ddd --debugger /opt/msp430-toolchain/bin/msp430-gdb --gdb
then at the (gdb) console prompt
(gdb) target remote :2000
How to Display Special Function Register Values without looking up every single one
It appears that the SFR's ARE all in there, and all that is required to access them is to add an underscore
to the END of the SFR name and then add a * to the beginning of it to dereference the pointer to see what the value is. Not as easy as just a right click, but not as painful as looking them up one at a time.
sudo cp ~/Downloads/ti_3410.fw