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

[a . doesschate]

On Tue, Oct 08, 2002 at 11:20:26PM +0000, Karl Ran wrote:
> Hi Armand,
> 
> >Here are my results :
> 
> Just for the record: Do you know the FW-version of your Atmel box?


I don't know what you mean but I like surprises ...


> 
> >On chip debug                state change (T)        DR/IR state (T)
> >communication freq.
> >according to Atmel
> >
> >125 KHz                      8.5                     10 - 12
> 
> OK - lets do some math:
> RAW worst-case bitrate would be:
> 1/8.5E-6 * 3 = 353 kbit/s (3 signals: TMS, TDI, TDO)
> 
> Thats more than 92 kbit/s (115.2 / 10 * 8)
> 
> So, we _have_ to either use another interface or do some data processing in 
> the JTAG-sniffer chip.(to reduce the bitrate)
> 
> Or we hope that the effective JTAG data-rate is low enough to buffer some 
> bits in the on-chip SRAM...
> 
> 
> Any opinions or comments?

Ok, let's see. What I intend to do is to get all the signals n one read cycle
i.e. TDI, TDO, TMS. All JTAG actions take place on the leading edge of TCK.

If we connect TCK on an alternative pin with edge interrupt capability then we
shouldnot miss any TCK leading edge.
If we connect TDI, TDO and TMS on portB then whenever a leading edge of TCK
occurs then portB will be read in in the corresponding interrupt service 
routine.
These signals will be put in a round robin buffer : a semaphore will signify
how much bits must be processed. 
If I am not mistaken this whole process of recording will take place within 
3 microseconds with a 16 MHz system clock of the ATmega16. I will verify this
value again.
In the main loop the buffer will be emptied until this semaphore reach zero
count.
The RS232 interface is just a copy of this interrupt service routine : so
115 Kb should be fast enough to dump the recorded JTAG message.
To record one data byte completely will lasts 80 microseconds anyway if we use
100 KHz on chip debug communication frequency (8 bits * 1/100KHz).

TMS signals a state machine : this means the sniffer is just a big switch/case
statement. A "big" effort must be done to filter out TDI and TDO : some 
bit shifting and completing a byte and putting it into a messsage array. The 
other
states can be changed rapidly and donot contribute anything. (This is also
valid for the JTAG ICE too !).

So if we set the JTAG ICE at the lowest possible "on chip debug communication 
frequency" (i.e. 100 KHz) and send every command seperately, then there should 
be
a fair chance to get everything we need.

As far as I 've seen it can be handled very quickly if we will use all the 
registers
as variables and pointers. I optimized all of it to gain maximum speed without 
sacrificing "maintainibility". If manufacturers try to hide features the tool 
must
be changed easily.

Two things I must add : for now I make an assumption that some features will not
be used like a pause and exit2 stage. But this is easily implemented too.
I don't have a facility to make my tool accessible to the public so if someone 
has 
this feature I'll be glad to hear.

<snip>

Armand


*******************************************
* choose GNU/Linux : GNU/Linux is Freedom *
*******************************************

----------------------------------

Armand ten Doesschate
Welschapsedijk 141
5652 XL Eindhoven
the Netherlands
tel : (++31) 40 2571 274
e-mail : address@hidden
avr-gcc-list at http://avr1.org