I can answer some of these questions:

1. I have built a driver for the msp430 UIF box that is available, with
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 the
other a sample executable. I pretty much just deal with basic functions
like download, peek and poke, etc. I do not support 2-wire or upgrading of
the UIF itself.

2. The "official" TI driver for the msp430 UIF was made to work about 1
year ago and is available in object form only. It is supported to some
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 to
map things to linux. This is why I think it must support all the same
functions as the WINDOWS driver. I do not use it.

Robert


>On Mon, 18 Jun 2007 16:37:10 -0000, Grant Edwards <grante@visi.com>
>wrote:
>
>>On 2007-06-18, Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>>
>>>>> Debugging support, though?
>>>>
>>>>Yes.  gdb has supported the msp430 for ages.
>>>>
>>>>> (My guess is that this would require TI to disclose details
>>>>> they probably aren't interested in having become "open
>>>>> source.")
>>>>
>>>>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.
>>>
>>> Ah.  There it is.  That is congruent with my expectations.
>>>
>>> Who developed this library
>>
>>Some guys who worked on the other open-source tools and signed
>>an NDA.
>>
>>> and does TI control it?
>>
>>No.
>
>Interesting.  That's good to hear.
>
>>> Or is the control of the source of that library out of TI's
>>> hands?
>>
>>That is my understanding.
>
>Thanks.
>
>>> Also... does TI allow most anyone to sign the NDA to gain
>>> access to the source?
>>
>>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.
>
>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.
>
>>> 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.)
>>
>>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).
>
>Makes sense.
>
>>>>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.
>>>
>>> Yes.  And I note that you carefully chose to mention
>>> 'downloading' in yuor comments about supporting the 2-wire.
>>
>>As I understand it, downloading/programming flash doesn't
>>require the closed source stuff.  Only debugging does.
>
>Yes, that's my gathering of it, too.
>
>>> Does this mean that debugging is not yet supported over
>>> 2-wire?
>>
>>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.
>
>Good to hear.  Thanks.
>
>Jon
>
>
>>
>>> Or am I reading you too closely?
>>
>>I was a bit sloppy in my wording.
>

Eric wrote:
> On Jun 19, 4:23 am, David Brown <d...@westcontrol.removethisbit.com>
> wrote:
>> The Freescale BDM interfaces are not exactly JTAG, but they are fairly
>> similar, and they are well documented.
> 
> 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).
> 

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.

> 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?
> 

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

> 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.
> 

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.

> Eric
>

On Jun 19, 4:23 am, David Brown <d...@westcontrol.removethisbit.com>
wrote:
> The Freescale BDM interfaces are not exactly JTAG, but they are fairly
> similar, and they are well documented.

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

On Tue, 19 Jun 2007 10:23:18 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>Jonathan Kirwan wrote:
><snip>
>> 
>> 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.
>> 
><snip>
>
>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

Jonathan Kirwan wrote:
<snip>
> 
> 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.
> 
<snip>

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

On Mon, 18 Jun 2007 13:18:40 -0700, Eric <englere_geo@yahoo.com>
wrote:

>On Jun 18, 1:30 pm, Jonathan Kirwan <jkir...@easystreet.com> wrote:
>
>> >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.
>>
>> I tried, already, to sign one.  Unless I was a tool vendor, they
>> weren't interested.
>
>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.
><snip>

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

On 2007-06-18, Eric <englere_geo@yahoo.com> wrote:

> 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).

There is an equivalent msp430.so for Linux.

> 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.

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:

  http://lists.sourceforge.net/lists/listinfo/mspgcc-users
  http://dir.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user

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

  http://www.soft-switch.org/downloads/mspgcc/

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!!

On Jun 18, 1:30 pm, Jonathan Kirwan <jkir...@easystreet.com> wrote:

> >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.
>
> I tried, already, to sign one.  Unless I was a tool vendor, they
> weren't interested.

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

On Mon, 18 Jun 2007 16:37:10 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2007-06-18, Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>
>>>> Debugging support, though?
>>>
>>>Yes.  gdb has supported the msp430 for ages.
>>>
>>>> (My guess is that this would require TI to disclose details
>>>> they probably aren't interested in having become "open
>>>> source.")
>>>
>>>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.
>>
>> Ah.  There it is.  That is congruent with my expectations.
>>
>> Who developed this library
>
>Some guys who worked on the other open-source tools and signed
>an NDA.
>
>> and does TI control it?
>
>No.

Interesting.  That's good to hear.

>> Or is the control of the source of that library out of TI's
>> hands?
>
>That is my understanding.

Thanks.

>> Also... does TI allow most anyone to sign the NDA to gain
>> access to the source?
>
>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.

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.

>> 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.)
>
>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).

Makes sense.

>>>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.
>>
>> Yes.  And I note that you carefully chose to mention
>> 'downloading' in yuor comments about supporting the 2-wire.
>
>As I understand it, downloading/programming flash doesn't
>require the closed source stuff.  Only debugging does.

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

>> Does this mean that debugging is not yet supported over
>> 2-wire?
>
>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.

Good to hear.  Thanks.

Jon


>
>> Or am I reading you too closely?
>
>I was a bit sloppy in my wording.