RE: [avr-gcc-list] jtagice and stk500 protocol docs

[J.C. Wren]

Or just use a logic analyzer in state mode...

        --John


-----Original Message-----
From: address@hidden [mailto:address@hidden
Behalf Of Jason Kyle
Sent: Monday, October 07, 2002 16:45
To: Karl Ran; address@hidden; address@hidden
Cc: address@hidden
Subject: Re: [avr-gcc-list] jtagice and stk500 protocol docs


At 08:24 8/10/2002, Karl Ran wrote:
>>The proprietary stuff is the jtag debugging protocol implemented within
>>the silicon of the AVR devices. This is what you guys propose to reverse
>>engineer and is the interface from the jtagice to the device.
>
>The good thing is that the low layer of the protocol is compatible with
>ieee1149.1(aka JTAG).

Wouldn't be JTAG if it wasn't !!

>We have to find out what the 4 commands do:
>
>PRIVATE0; $8
>PRIVATE1; $9
>PRIVATE2; $A
>PRIVATE3; $B

Looked into this a while ago and purchased an stk500/501/jtagice with a
particular goal in mind :)  The JTAG clock is slow as from Atmel's JTAGICE
box, a few hundered kHz at most from memory.  My conclusion was a piece of
hardware needed to be built to capture the private command sequences from
TAP and log, probably quite feasible to do this with another micro and
squirt rs232 to a PC.


>The Mega128 pdf says:
>All read or modify/write operations needed for implementing the
>Debugger are done by applying AVR instructions via the internal AVR
>CPU Scan Chain. The CPU sends the result to an I/O memory mapped
>location which is part of the communication interface between the
>CPU and the JTAG system.
>
>So, it shouldn't be that difficult...
>
>>If you guys can successfully rev-eng the lower level interface, there may
>>still need to be a piece of hardware sitting between gdb and the device
>>which could be similar to the atmel jtagice box, but completely open and
>>compatible, possibly even using the same avrstudio <-> jtagice protocol.

It's on the drawing board.  An updated version of my pAVR programmer will
do this job just nicely.  mega8 based, same size as original and also
usable as an SPI programmer.


>Well, if we want to push gdb, we have to make it incompatible ;-)

Have to admit I keep wondering why I bother aiming to make stuff compatible
with Atmel's tools, all it does is allow people to be lazy and not learn
about GNU/Linux systems......  Perhaps we should just scrap Atmel's jtagice
protocol (rs232 side) and go with gdb serial?  No need to burn up Ted's
time moving avarice into gdb then.



>Karl,
>who is not sure which mailing list would be OK for these topics :-/

I have no problems with the discussion being on this list, it is avr tool
related so is on topic.  If anyone doesn't like it email me with your
reasons.

Jason Kyle
list admin

avr-gcc-list at http://avr1.org


avr-gcc-list at http://avr1.org