Hi all,
I have put the first test version of rproxy on the mspgcc web site. This
is a new program which sits between msp430-gdb and the TI Flash
Emulation Tool (FET - also known as the parallel port JTAG tool). rproxy
understands the gdb remote protocol over TCP/IP connections, and it
understands how to control an MSP430 via. a FET. Used with Insight, or
one of the other GUI front ends for gdb, this allows full debug support
- quite similar to the existing IAR and Quadravox tools. Now we have s
full suite of tools for the MSP430.
rproxy is based on the rproxy 0.7 program which can be found at
http://world.std.com/~qqi/labslave/rproxy.html. It was intended that the
MSP430 code just be added to the existing rproxy code. However, the
rproxy code has now been so heavily modified it looks like it has
forked. Sorry. Forking is bad.
Because rproxy relies on proprietary code from TI the full source code
cannot be opened at this time. The generic code (i.e. the modified
rproxy code, less the MSP430 specific parts) will be made available when
a few more things have been tidied up. You cannot build an MSP430
debugger with just that source code, but we hope it may be useful to
people trying to build similar tools for other processors.
What is on offer right now is binary test versions of rproxy for Linux
on i386 and Windows. They are being used, perhaps even as you read this,
to debug real MSP430 programs. They support most of the gdb remote
protocol, including some of the obscure stuff (like CRC32'ing a memory
block).
For the Linux inclined we offer
http://mspgcc.sourceforge.net/rproxy-linux-20021030
For Windows users we have
http://mspgcc.sourceforge.net/rproxy-20021030.exe
which should be used with
http://mspgcc.sourceforge.net/HIL.dll DLL
Remember these are works in progress, but they are doing useful work for
me. The source for HIL.dll can be found in CVS (this part is currently
open source).
The following limitations should be noted:
The IAR and Quadravox tools both loose control of the MSP430 at times.
rproxy does too, but it has the benefit that it doesn't seem to dump
core with the same regularity :-) It should be very hard to loose
control of the target device - only issues related to certain power
saving states are supposed to be able to do it. This will be
investigated, as it is real a pain.
gdb is a general purpose tool. We need to live with what is does. One
odd thing it does is choose some strange block sizes in which to
download code by the remote protocol. When it uses large blocks, writing
to flash is reasonably fast. When it sends tiny blocks, writing to flash
gets slowwww...... Some caching is currently being done, but
improvements are needed. If I fully cache the data any write errors will
not be reported in a timely manner. I am not clear what the best
solution might be.
It is advisable to put the following in your .gdbinit file:
set remoteaddresssize 64
set remotetimeout 999999
to make rproxy behave nicely.
The linux version requires access to /dev/parport0. The default
permissions on many Linux distributions only allow root to do this.
Change the permissions, and all should be well. The Linux binary was
build on a RedHat 7.2 machine. The Win32 build was built with mingw32.
If you run rproxy without parameters it will display some help. A
command like:
rproxy --port=3333 msp430
is what you need to get it going. If you then run msp430-gdb (with or
without insight) and connect to a remote target by TCP/IP at port 3333
you should connect to rproxy. Special MSP430 features, like erasing the
flash, are accessed through gdb's monitor commands. "monitor help" will
tell you what they are. "monitor erase" is the most important one.
"monitor identify" is handy, too. If you have trouble try
rproxy --port=3333 --debug msp430
or even
rproxy --port=3333 --debug --debug msp430
and you will see a little or a lot of trace information. I can't output
debug about what is happening on the JTAG interface (I'm not allowed
to), but rproxy displays quite extensive info about what is happening on
the gdb interface side and internally.
Have fun.
Report problems.
Don't complain it isn't perfect - even I am not :-)
Regards,
Steve
