Re: Re:[avr-gcc-list] JTAG interface

[David Brown]

> >> I was just wondering if it's possible to use the JTAG interface of the
> >> AVRs without any special ICE.. I mean, using just some cables and
resistors,
> >> even diodes, but nothing complicated..
>
> > uisp -dprog=xil
>
> That's nice (misusing JTAG cable for MISO/MOSI etc.), downloading
> programs via cheap JTAG cable really connected to ATmega's JTAG is
> also nice (using AVRSVF) - BUT can we also have gdb connected to
> ATmega16+ via cheap printer-port JTAG ???
>
> That would be very very nice (having great debug ability for nearly free).
>
> I mean something like this:
>
>  gdb debuger (with ddd)
>     |
>  AVaRICE patched to talk to thing below instead of serial line
>     |
>  'AVR JTAG ICE' in software on PC
>     |
>  Printer Port
>     |
>  Cheap JTAG dongle (*)
>     |
>  ATmega16 or 32 or 64 or 128
>
>
> Is there any principal problem with this? Or does it work for somebody
> somewhere?
>
> I can imagine just the following problems:
>
> 1) Debugging via ATmega's JTAG requires signals too quick to
> generate/percieve on the PC's printer port - I know no details here
> but I hope this is not the case.
>

I think that's unlikely - jtag is normally synchronous, and can run as
slowly as you like (it could well be, however, that a parallel-port based
jtag debugger for the avr would be slower than the jtag ice, depending on
how much handling is done locally on the jtag ice.  But it should still
work).

> 2) Protocol normally found on RS232 to AVR JTAG ICE is unknown - I
> guess it is now known because AVaRICE exists.
>

I think that this protocol is (at least mostly) known.

> 3) Some commands of protocol normally found on JTAG between AVR JTAG
> ICE and ATmega16+ are not known - I guess at least they are known to
> those who make cheaper AVR JTAG ICE clones so future authors of 'AVR
> JTAG ICE in software on PC' could find out as well.
>

This is the sticking point.  Some of the commands are known (Atmel publishes
the commands for programming the chips, which makes it possible to use other
jtag interfaces for programming), but those involved in debugging are not
known.  The jtag ice clones work by being clones - they include the same
chips as the original, and start with no firmware (other than perhaps a
small boot program - I'm not entirely sure).  When the device is connected
to a PC running AVR Studio, AVR Studio believes the device to be an original
avr ice, and thus updates its firmware.  It neatly avoids the issues of jtag
ice to avr communication.

Incidently, does anyone know what the legal status of these devices is, and
what Atmel's reaction to them is?


The problem is that Atmel do not want to give out information about the
debugging jtag commands.  I'm not sure I understand the reasoning, and I am
probably mixing it up with TI's reasoning (they were in the same position
regarding the msp430 - although they already use a cheap parallel port jtag
debugger, they kept the debugging protocol under tight NDA), but I think
there are two reasons - if they keep tight control on the protocol, they can
change it in the future and notify the few developers who have used it,
whereas if it is out in the open, then backwards compatibility is much more
of an issue.  The other reason is that if anyone can make cheap debugger
tools, then they fear the use of shoddy tools will cause people to think the
chips are unreliable rather than the tools.  It doens't take much thought to
counter these two arguements, but that is at least what I heard (and again,
it may have been regarding TI rather than Atmel).

There are perhaps three possible solutions to this.  One is to persuade
Atmel that it makes more sense to give out information on jtag debugging (I
have no idea what they might think of this, as I've never asked them).  A
second is to stick a logic analyser between a jtag ice and a modified
AVaRICE program and use good old fashioned reverse engineering - it should
be perfectly possible, but it's a lot of effort and there may be bits
missing.  The third idea would be to take a leaf from the msp430-gdb crowd,
and have some keep developer sign an NDA with Atmel and write an rproxy
variation to handle the gdb-to-hardware step rather than AVaRICE (rproxy has
a BSD license, so it is possible to distribute binary-only copies and thus
preserve the NDA).


> All together, it seems to me that super-cheap super-debug capability
> is possible yet I do not see this described anywhere - so what is the
> problem? Just nobody did it yet? Most likely I am missing some very
> basic thing...
>
> Thanks for any comments.
>
> Vaclav Hanzl
>
> (*) For example this one:
>   http://www.lart.tudelft.nl/projects/jtag/
>   http://www.tuxscreen.net/wiki/view/JTAG
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list
>



_______________________________________________
avr-gcc-list mailing list
address@hidden
http://www.avr1.org/mailman/listinfo/avr-gcc-list