Steve,
I've just begun to use gcc with the FET msp430f149, thanks to your fine
work on rproxy. I had been limping along with the freebie IAR toolset
in hopes that somoe would get gdb/FET working, and thankfully that has
happened. Finally, I can go back to Linux land and to do my development.
I'm still getting used to everything, so I'm hesitate to say whether
there are any real problems with rproxy or not. I can tell you that it
seems to work well enough so far. My only complaint is the slow load
problem that occurs when gdb uses small blocks. Do you have any insight
into why the block size varies?
I notice that rproxy times out on gdb after each block, and that seems
to be where the big delay is between blocks. I get this message when
from rproxy after each block.
"msp430-rproxy: timeout while reading from GDB"
Please advise if you have any work around for this problem.
Regards,
Walt Spicker
Steve Underwood wrote:
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
