TI's MSP430-F2013 USB DevKit & mspgcc

I check in on this issue periodically myself, but I haven't yet managed to get it working. It's a pity there is not a big vendor- supported gcc-bundlin' body for MSP430 (a la WinAVR) because theoretically all the documentation is available and it's "just" a matter of writing an implementation.

There are reports that it can be made to work under Linux, but it still seems to require a lot of futzing around.

TI is aware of mspgcc and vaguely supportive, but they could do a lot better...

--
Grant Edwards
grante@visi.com

I doubt Linux will work with the downloader/debugger.

Without any reasonable downloading support, there is no point in porting gcc for it.

There are quite a few people on the mspgcc list that say it does work for them. I suppose they could all be liars, but some of them are people for whom I have a fair bit of respect and I'd believe them before I'd believe you.

GCC has been ported for years. There has downloading support for parallel JTAG and USB interfaces for a long time. There is also downloading support for the new two-wire debugging interface -- it's just not in "vanilla" Linux kernels. IIRC, you have to compile a patched USB serial driver for it, and edit one of the USB subsystem files to add a vendor/device ID.

--
Grant Edwards                   grante             Yow!  .. Should I get
                                  at               locked in the PRINCIPAL'S
                               visi.com            OFFICE today -- or have
                                                   a VASECTOMY??

Debugging support, though? (My guess is that this would require TI to disclose details they probably aren't interested in having become "open source.")

Jon

Yes. gdb has supported the msp430 for ages.

Gdb uses a daemon that talks to the JTAG interface widget and acts as a gdb-server on a TCP port. That daemon uses a library for which source is unavailable unless you sign an NDA.

TI recently came out with parts that use a proprietary 2-wire debugging interface called "spy-by-wire" instead of the standard JTAG interface. That interface presents a 2-port USB-serial interface to the host which required a patch to the USB-serial device. Support for the USB-serial dongle that talks to that 2-wire interface is what the OP was asking about.

--
Grant Edwards                   grante             Yow! Is this an out-take
                                  at               from the "BRADY BUNCH"?
                               visi.com

Ah. There it is. That is congruent with my expectations.

Who developed this library and does TI control it? Or is the control of the source of that library out of TI's hands? Also... does TI allow most anyone to sign the NDA to gain access to the source? Or are they pretty picky about it and pretty much would refuse most such inquiries unless they considered them well-justified from their own marketing point of view?

(From your following note, presume my above questions are related to the earlier JTAG and not the 2-wire interface unless it applies.)

Yes. And I note that you carefully chose to mention 'downloading' in yuor comments about supporting the 2-wire. Does this mean that debugging is not yet supported over 2-wire? Or am I reading you too closely?

Jon

Some guys who worked on the other open-source tools and signed an NDA.

No.

That is my understanding.

I don't know. I haven't attempted to gain access to the source, but I know you don't have to work for a commerical tool vendor.

The same library is used for all of the interfaces, so it doesn't really matter which interface you talk about. The older interfaces (e.g. parallel port JTAG) have had support for longer than the new interfaces (e.g. USB 2-wire).

As I understand it, downloading/programming flash doesn't require the closed source stuff. Only debugging does.

Yes, debugging via the 2-wire interface is supported (and has been for a little over a year now). The 2-wire stuff was introduced last spring, and it took a few weeks after introduction of the 2-wire stuff weeks for the open-soruce tools to catch up.

I was a bit sloppy in my wording.

--
Grant Edwards                   grante             Yow! This PIZZA symbolizes
                                  at               my COMPLETE EMOTIONAL
                               visi.com            RECOVERY!!

Interesting. That's good to hear.

Thanks.

I tried, already, to sign one. Unless I was a tool vendor, they weren't interested. Even with some meaningful business attached to the idea. So this may be a sea-change I was unaware of. I need the capability for some products I do -- the ability to develop my own custom debug tools. ARM is nearly the only processor where I can find that doc placed in the manual and without having to pull teeth to get it. I'd be interested in anyone's comments about other processors where the debug JTAG interface isn't too complicated to get.

Makes sense.

Yes, that's my gathering of it, too.

Good to hear. Thanks.

Jon

There's actually 2 levels of undocumented debugging docs you can get access to. The first one is specific to Windows and it documents the interface for the msp430.dll file that talks to the chips. This is all you need on Windows and it supports JTAG and Spy-bi-wire. They will allow most people to sign an NDA to get access to that. They actually have a lot of supporting documentation and sample code for this - I was quite surprised. They sent me a link to download a huge zip file full of cool information. I had a second Christmas when I got this.

The second level is the actual chip control registers and wire signals. This is the one you'd need on linux, since msp430.dll wouldn't work for you (not counting the possibility of WINE, which I'm not super fond of). They did NOT give me access to this level of information. I don't know if they would do this if I bother them more about it.

By the way, I'm porting my Windows EmbeddedGNU IDE to linux, and I'd sure like to support linux debugging if I can figure out all the issues with making it work on linux. The msp430 is still the best MCU for general purpose low power requirements.

Eric

There is an equivalent msp430.so for Linux.

AFAICT, there are three options:

1) You could talk gdb remote protocol to the existing msp430-gdbproxy daemon. I would think that would be the easiest thing to do, since the gdb remote protocol is well documented and there are example implementations you can look at. [It is a bit of a hassle at run time to start up the daemon.] It would mean your IDE could easily be made to work with various other JTAG interfaces (for other architectures) which talk GDB remote either natively or through a closed-source daemon. It's also nice because you get remote debugging "for free." 2) Get API info for the lbraries used by msp430-gdbproxy, and just use the binary library files that are currently available. 3) Get the API for the ddebugger unit in the core and write your own library.

You might want to ask about the availability of library API info on the mspgcc mailing list:

The maintainer of msp430-gdbproxy will likely know the answers to your questions. The place to get the proxy program and the libraries is

It's possible I've misunderstood how msp430-gdbproxy was done and that TI provides the library in object form along with API info, but I thought that the library and gdb-proxy were both maintained by somebody outside TI.

--
Grant Edwards                   grante             Yow! I just heard the
                                  at               SEVENTIES were over!!  And
                               visi.com            I was just getting in touch
                                                   with my LEISURE SUIT!!

It is the 2nd level you mention that I'd need to have access to. I would be developing a custom device that would be a remote (handheld) device (non-Windows, entirely embedded code of mixed asm and c) that would attach to a commercial product we also sell and would allow some special diagnostics to be done on-site, in-situ. I would not use either Linux or Windows in that situation so pieces of software by someone else are out of the picture. ARM still remains the easy path here, it seems.

Jon

The Freescale BDM interfaces are not exactly JTAG, but they are fairly similar, and they are well documented. The version used on the ColdFire microcontrollers is particularly easy to work with - I have made my own downloader using the interface (I did not make a debugger, since gdb does a perfectly good job, the documentation is there if you want it).

mvh.,

David

Thanks. At least there is one more to add to the pile. I'll take a look at ColdFire to see if there is anything about it to differentiate it positively from each and all of the various ARM incarnations.

Jon

I've only worked with BDM on the hcs12, but from what I've seen it's completely documented in open literature, and it's also about 100 times easier to use than JTAG for debugging (memory inspection and modification, single-step, breakpoints, flash programming).

BDM doesn't support a real JTAG style chain, but I don''t need that anyway. The Coldfire has both BDM and JTAG, I think?

I'm just not too happy with the mostly Ethernet niche of the Coldfires. They're trying to break out of that and become more general purpose, but I don't know how well they're succeeding. Arms are plentiful and have a lot of features, but they're harder to code at a very low level.

Eric

The only annoying thing about the BDM is that the serial transfers are done in 17-bit blocks, which doesn't fit standard SPI ports very well.

It has both, but the JTAG is for continuity and board testing rather than debugging.

I've used ColdFires for many things other than Ethernet (in fact, I haven't tried Ethernet yet). There are a lot of different ColdFires with different peripherals, but they are playing catch-up with ARMs in some areas. For example, there are nice powerful single-chip ColdFire devices with Flash and RAM onboard - comparable to ARM7 devices in power and price, but later to the market. The upcoming v1 core ColdFire devices will be smaller, cheaper, and lower power than existing ColdFires - but again, they'd have been far more newsworthy a year or two ago.

I can answer some of these questions:

1. I have built a driver for the msp430 UIF box that is available, wit TI's permission, in source code form. I do not support this code at all but it use it a lot. The code is really two files: one is a library th other a sample executable. I pretty much just deal with basic function like download, peek and poke, etc. I do not support 2-wire or upgrading o the UIF itself.

1. The "official" TI driver for the msp430 UIF was made to work about year ago and is available in object form only. It is supported to som extent. It works with gcc. I think it supports 2-wire but I am not 100 sure. It is based on the official WINDOWS driver code, with some ifdefs t map things to linux. This is why I think it must support all the sam functions as the WINDOWS driver. I do not use it.

Robert

What is the official distribution point for this driver?