Hi All,
Below are my build notes for the toolchain. I've built complete,
working chains
under Linux (Fedora-core1, kernal 2.4.22, native gcc-3.3.2) and
MacOS-X (Panther/10.3, apple's native gcc-3.3 from cost-free Xcode
distro)
Numbered items below are indicated as "*)" because I got annoyed at
renumbering
them repeatedly.
BTW, these instructions are NOT NECESSARILY CORRECT.
They just represent what I've reconstructed from my own experience.
No Warranty expressed or implied, Use At Your Own Risk, etc.
Please edit/update/whatever as neccessary to make 'em useful.
My current development environment is emacs/mspgcc/mspgdb/ddd on
the Mac, talking to gdbproxy on my linux box (thinkpad) which has the
TI parallel JTAG adapter plugged into a FET430P140 from TI's little
dev kit. I've dropped the IAR tools, and given my boss back his windows
machine. At the moment, it looks like we'll be doing all our
msp430-based
development in these two environments. (we're new to msp430)
-Ethan
Instrument Lab
Lamont-Doherty Earth Observatory of Columbia University
------------------------------------------------------------------------
-------------------------
This is a short set of build instructions for the msp430-gcc
cross-compiler toolchain. These instructions have been
derived from my build experiences under Linux and MacOS-10.3
Ethan Gold <[email protected]>, 2/26/2004
------------------------------------------------------------------
Required Packages:
(versions listed are the _minimum_ requirements. YMMV with
newer revisions (and newer is usually better))
* binutils-2.14 source
Any official gnu binutils package will do, I think (gnu.org??)
* gcc-3.2.2 source
From http://gnu.org/ or other
* msp430-gcc source (latest, preferably)
From mspgcc.sourceforge.net
* gdb-6.0 source
From gnu.org or other
* gdb-current from mspgcc.sf.net CVS
read mspgcc site instructions on how to access their CVS
(list instructions here)
* msp430-libc most recent, or from CVS
same as above
* gdbproxy from mspgcc.sf.net CVS
linux-only as it uses linux parallel port driver routines
* other JTAG tools: See Chris's reply to my question at the
bottom of this file. (summary: use gdbproxy or pyjtag under
linux or build the serial JTAG box yourself from the schematic)
(The JTAG tools other than gdbproxy are ignored here because
I got so confused between them all that I couldn't document which
does what, though I DO seem to know how to run them...)
Note before getting started: KNOW YOUR NATIVE DEV TOOLS
I spent forever trying to build gcc under Darwin-10.3 before I found
out I had the older gcc build from apple. It's not obvious, but the
Xcode
package from developer.apple.com will install the RIGHT version of
gcc-3.3 for Darwin. I snubbed Xcode 'cause I don't like graphical
dev environments (luddite), and amn't building Aqua apps.
Compilers are viscious to build, beacuse they are compiled in several
stages, and a gcc build is a rigorous benchmark of your toolchain.
Be confident in your existing tools before you begin. You've been
warned...
Note:
A neat side-effect of using gdbproxy is that ONLY gdbproxy need be
running on the
machine connected to the actual target. EVERYTHING ELSE can be running
on a
remote machine with the development toolchain, including the debugger.
For instance,
I have a linux machine with gdbproxy running, and a MacOS laptop with
msp430-gcc,
msp430-gdb, ddd, and emacs. I can do all my development and building on
the Mac,
using gdb to pass the binaries to the target via gdbproxy.
THEREFORE: gdbproxy must be built natively on the machine with the JTAG
adapter. Everything else may be on another platform.
These are the configure args which you should use across all the builds.
It's best to be consistent. Gcc however, supports multiple targets and
versions in its
standard installation infrastructure, so you can use /usr/local as
gcc's prefix
and let all your gcc cross-compilers fall into
/usr/local/lib/gcc-lib/_arch_/_version_/
Please do the steps below in order - the configure args are here for
reference.
Recommended configure args:
* for gcc: --prefix=/usr/local --program-prefix=msp430- --target=msp430
* for most all else: --prefix=/usr/local/msp430
--program-prefix=msp430- --target=msp430
*) Create a directory to hold all your builds.
*) Unpack binutils, gcc, and gdb.
*) Unpack the msp430-gcc source on top of the gcc sources (it adds
files)
*) Unpack the msp430-libc pacakge - CVS or download from mspgcc.sf.net
*) Unpack the gdb-current sources (or move them) on top of the gdb
sources (adds files)
*) Unpack gdbproxy
*) build and install binutils first using above args
If the ld/ldscripts directory does not get copied to
/usr/local/msp430/lib/
automatically, you'd better copy it in by hand so you have:
/usr/local/msp430/lib/ldscripts/_blah_*
*) link /usr/local/msp430/bin/msp430-as to "as" in the same directory
because when msp430-gcc invokes the assembler it's not clever enough
use the same naming convention for "as" that it's built with.
Or I could be doing something wrong, but this happened every time...
(Can't remember now - shoud this only be done after the build fails
and then the build continued?)
*) put /usr/local/msp430/bin in your path before /usr/bin
to make sure the new "as" gets called
*) create another directory such as "gcc-3.x.x-obj" in your
main build directory in which to do the gcc build
*) run configure from within the obj directory as ../gcc-3.x.x/configure
*) build gcc, make install.
make a backup copy of /usr/local/lib/gcc-lib/msp430/3.2.2/specs
and then edit it so the "*invoke_as:" line calls "msp430-as" instead
of just "as".
If your build fails looking for ftp-bit.c:
copy gcc-3.2.2/gcc/fp-bit.c to gcc-3.2.2-obj/gcc/ (a build bug)
*) remove the link /usr/local/msp430/bin/as
now your native and cross-compile tools shouldn't conflict.
*) build msp430-libc in place using /usr/local as the prefix in the
makefile, make install
(the Makefile will append "msp430" to install the libs in
/usr/local/msp430/lib&include
If this works, it means your toolchain works.
Once libc is built, you can write actual code or compile the
examples.
*) build gdbproxy and put it somewhere useful like
/usr/local/msp430/bin/msp430-gdbproxy
*) build gdb in place using the same args as above, make install.
*) run msp430-gdbproxy in a separate terminal to watch the debugging
info
This will connect to the target over the parallel port and open
a local
tcp port for talking to gdb. Make sure your lpd or cupsd isn't
monopolizing
lp0.
create a ~/.gdbinit (can you do this in a dev directory?)
containing:
set remoteaddresssize 64
set remotetimeout 999999
target remote localhost:2000
(or: target remote jtaghost:2000)
run msp430-gdb to download and run a test on the target:
(gdb) monitor erase all
(gdb) load yourtest.o
(gdb) continue
*) You should be able to run ddd with the argument "--debugger
msp430-gdb"
to get a good graphical debugging environment. Just remember to do
"continue"
instead of "run" with the msp430 because there's no OS loading
component, just
telling the CPU to start executing.
I have problems using the "monitor" command, or "load" after the
first time
because gdb thinks the target is no longer the remote jtag device,
or something.
------------------------------------------------------------------------
-----
Chris Liechti's message regarding JTAG hardware and software
------------------------------------------------------------------------
-----
Return-Path: <[email protected]>
Message-ID: <[email protected]>
From: Chris Liechti <[email protected]>
To: [email protected]
Subject: Re: [Mspgcc-users] serial and parallel jtag hardware w/ mspgcc
tools?
Date: Tue, 10 Feb 2004 20:34:05 +0100
Ethan Gold wrote:
> I have both the TI serial and parallel jtag adapter units, and was
under
> the impression that the pyserjtag and pyjtag tools would work with
them,
> but the documentation is not very clear. Now I think that it will
only work
> with this circuit diagram I finally found on the website. Does this
diagram
> implement a functionally equivelent serial jtag box to the TI
version?
yes, pyserjtag is for that box, for which you can find the schematic on
our website, somewhere... it's not compatible to other serial
programers.
pyjtag uses the usual jtag adapter desing that comes with all the FET
kits from TI. other vendors also sell adpaters with that cicuit or a
compatible one.
> What I really need is for the serial jtag adapter to work, as there
are few
> parallel ports implementations for modern MacOS machines, and the
> API's will surely never be supported if there is a RS232 alternative
(which
> is just fine with me).
mind you, the pyserjtag adapter does only support programming, NO
debugging.
if you just want do download thats fine then, but then you can also have
an other alternative: the BSL. the MSP has a built in ROM that allows
programming over the serial port.
> So... what's the story with the jtag communications tools? Can I use
them
> with the TI JTAG boxes?
TI-hw down-/upload debugg/GDB PCcon MSPcon wires(3)
pyjtag: yes yes yes parport JTAG >=5
pybsl: - yes no RS232 ser 5
pyserjtag: no yes no RS232 JTAG >=5
gdbstub(1): - - yes(2) RS232 ser 3
(1): not yet implemented, but a possible solution: a small software on
the MSP, that talks GDB protocol over the serial line. that would allow
some debugging even w/o JTAG, but breakpoints could not be set
everywhere and there are other limitations.
(2): as mentioned in (1), there are limitations due to the the nature
Flash. you cant set breakpoints everywhere, the downloaded program would
need to have calls at the appropriate places. it requires a serial port,
it uses space in RAM/Flash, ...
(3): connection from the programer to the target:
JTAG: minimum 4 data lines + GND, RST recomended and TEST needed on some
targets.
BSL: GND, RX, TX, TEST or TCK and RST to activate the BSL
gdbstub: gdb protocol over the serial: GND, RX, TX
in the future we may support other programer hardware/connections too,
but i cant promise anything.
chris
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------
----
END OF FILE
