Well, that's certainly good news. I've used gdb in the past, and find
the
whole gdb process rather a PITA. I do debugging the old fashioned way:
printf() and wiggling I/O lines. All I need from the JTAG end is erasing,
programming, and telling it to run. Sounds like that's all there, so I
shall give that a try.
I should be slightly more specific about IAR. I only use C-Spy. IAR
tools
are *way* too expensive for small shops, so no matter how good they are,
they're out on their ear. C-Spy is junk. Trash. Garbage. Crap. Unfit
for human consumption. It's unreliable, it can't remember defaults, it
exits on many errors. I'm surprised it remembers what directory you last
downloaded from. It requires too much mousing around to do anything. Each
time you download, you have to reselect the programming interface to use.
What moron thinks you're going to be changing the interface *everytime* you
download? Sometimes it works for 20 or 30 downloads in a row, other times
it doesn't work at all 20 or 30 times in a row. "Retry? What's a retry?
We've never heard of that idea..."
If I released software that bad, not only would I not be surprised that
no
one bought it, I'd be surprised if *anyone* bought it. C-Spy is an
excellent exercise in how to write as poor a user interface as possible, and
still actually have it run periodically.
One day I shall be interested in hearing why TI (and Atmel, for that
matter) think that protecting parts of the JTAG command structure is a
useful idea. I believe in IP, and I believe there are some things that
users don't need to know about. But the fact they're willing to share that
information with some parties and not others is disturbing. It seems to
indicate a managerial structure that doesn't really understand what a user
wants, but rather a structure based on unfounded fears. Do they really
think some is going to clone the core because someone knows how to read a
register with JTAG? And if they aren't going to tell, the least they could
do is say why they think they shouldn't.
--John
-----Original Message-----
From: [email protected]
[mailto:[email protected]]on Behalf Of Steve
Underwood
Sent: Friday, October 25, 2002 00:03
To: [email protected]
Subject: Re: [Mspgcc-users] JTAG MSP-FETP430IF status
J.C. Wren wrote:
> What's the current status of being able to reliably program parts via
> JTAG
>with the parallel MSP-FETP140IF tool? I am sick and tired of this IAR
>*crap*. Half the time it can't sync with the target, and 90% of the time
>when it gets an error, the incompetent who wrote this atrocity decides it
>should exit.
>
> If anyone I ever run into asks about IAR, I going to advise in the
>strongest possible terms that they stay as far as humanly possible away
from
>this crud.
>
> --John
>
Is IAR really that bad? Most people I know using it are reasonably
happy. Quadravox is a much bigger pain. There, the whole package is in
one binary. When it crashe,s the whole IDE goes fut! At least with IAR
only C-Spy dies :-)
Work is in progress on a full debug solution for mspgcc using JTAG. The
issues are basically this. Preoprietary info is required from TI to make
this work. They have opened part of their JTAG interface code (see CVS),
which allows download by JTAG. The parts that allow debug by JTAG are
not (at least yet) open. An early version of a closed solution now
exists, and when clearance is given from the responsible party at TI
(next week I hope) test versions will be available as binaries.
For IP reasons the new debug tool works like this. gdb is GPL'ed, so we
can't link it against a closed source library. gdbserver (a remote proxy
interface for gdb) has the same problem. rproxy is a program available
on the web, which is somewhat like gdbserver. However, it has a BSD
style licence. Here, mingling of open and closed code is possible.
What Chris and I have put together is a heavily rewritten version of
rproxy, working with TI's JTAG interface library. It is working on both
Linux and Windows [possibly even with similar results :-) ]. We will
provide the modified core (i.e. non MSP430 specific) rproxy code as open
source, under it original licence. How much of the MSP430 specific code
is opened is for TI to decide. The gdb mods you can get from CVS right
now will build you a gdb or insight package that works with this. You
will be able to connect to our msp430-rproxy program from msp430-gdb by
TCP, and talk to the target from there using a parallel port link to a
FET emulation tool (just like IAR and Quadravox).
So, how well does it work? It is still a work in progress, but it has
quite a lot of functionality right now. It can erase flash, download
code, set breakpoints, run, single step, inspect memory and registers,
and so on. Like the IAR and Quadravox tools, it can get in a state where
is loses control of the MSP430 [though it doesn't keep core dumping on
you :-) ]. I am looking into why this happens, as I consider it one of
the more PITA qualities of the existing tools. Performance is also an
issue. Sometimes gdb downloads in big chunks (300+ bytes) and sometimes
in small ones (30 something bytes). Writing to flash is pretty
reasonable with the big chunks, but rather slow with the small ones. I
have been trying buffering strategies to avoid writing the little blocks
directly to the target, but there are side effects to this (like a flash
write error getting reported rather late, when you forgot to erase the
flash). I am still trying to achieve smooth and fast results.
As is usual with insight, and the other GUI front ends to gdb, you can
do most debug activities in a similar way to C-Spy - view intermixed
source and binary, click to control breakpoints, display memory and
register windows, etc. We haven't tried to do custom displays of the
state of the registers in a peripheral module, like IAR and Quadravox
do. I only remember using this feature once, which was basically just to
try it out. I don't, therefore, feel a string motivation to implement
this. It would be in the GPL'ed code, though, so anyone else who wants
to have a go is most welcome.
The bottom line is we have solution that keeps all the IP holders happy
- no GPL violations, TI still gets to keep their proprietary info
closed, and everyone gets all but a small amount of source code out in
the open with reasonable licencing conditions. The solution will
basically do all the key things that gdb allows [except thread handling
:-) ]. It will be available as Linux and Windows test binaries RSN.
Regards,
Steve
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
