Ok, super. Linux is Ok. Thanks.
How about BSD version? I can put some efforts to make a BSD binary. ~d On Wednesday 30 October 2002 19:34, you 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 -- ********************************************************************* ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 314-8860, 5585314 *********************************************************************
