J.C. Wren wrote:
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 :-)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
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
