JTAG TCK clock source?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I can't find any AC characteristics for the JTAG TCK.

What is the maximum frequency for AVR JTAG?

What is the clock source for JTAG TCK? Same as serial 2-wire bus timing? My guess is the same, since both use the serial shift registers.

thanks,
Patrick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What is the maximum frequency for AVR JTAG?

A trick question, as it appears that there is not one answer.

For boundary scan? It can be higher than the system clock frequency.
For ISP?

Quote:
During programming the clock frequency of the TCK Input must be less than the maximum frequency
of the chip. The System Clock Prescaler can not be used to divide the TCK Clock Input
into a sufficiently low frequency.

For debugging? Hmmm--is that really a "boundary scan" operation?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know why JTAG AC characteristics are not in the AVR data sheets. Either that or I'm not looking in the right place. Maybe an email to ATMEL or checking into Atmel's JTAG toolset.

It appears you answered my question. The TCK for SPI is the same TCK for JTAG?

Anyway, I was just too lazy to do all that before posting here. Lee, where did you find that info on the TCK? I just skimmed some mega datasheets. The IEEE standard does not specify speed, but leaves the chip manufacturer to specify that 'certain operations must be completed within a specified time from the rising or falling edge of TCK'. ATMEL does not provide as much information on JTAG timining as do other companies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

where did you find that info on the TCK? I just skimmed some mega datasheets

Searched the datasheet for all occurrences of TCK. ;)

Quote:

The TCK for SPI is the same TCK for JTAG?

You mean SCK for SPI operations?

For ISP, it should not be more than 1/4 the system clock speed. There are rules in the datasheet re max speed for SPI in slave and master modes. IIRC a master with the doubler option can do clk/2, and less than that for slave (clk/4?).

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Quote:

The TCK for SPI is the same TCK for JTAG?

You mean SCK for SPI operations?

For ISP, it should not be more than 1/4 the system clock speed. There are rules in the datasheet re max speed for SPI in slave and master modes. IIRC a master with the doubler option can do clk/2, and less than that for slave (clk/4?).

Lee

IEEE 1149.1-2001
-- JTAG TCK is externally applied. (I'll post more later when I can copy and paste from the document - some interesting stuff)

So the question is...

What is the maximum speed of TCK possible for the AVR? It has nothing to do w/ the AVR clock! It's internal propagation speed of the JTAG shift registers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IEEE Standard Test Access Port and
Boundary-Scan Architecture

Sponsor
Test Technology Standards Committee
of the IEEE Computer Society

Approved 14 June 2001

IEEE-SA Standards Board
Approved 25 October 2001

American National Standards Institute

Quote:
Many parts of the test logic perform operations in response to the rising or falling edge of TCK, as indicated by the use of the phrase "on the rising (falling) edge of TCK." These operations have to be completed within a fixed (frequency-independent) delay after the occurrence of the relevant change at TCK, and this delay has to be specified by the component supplier. Therefore, the phrase "on the rising (falling) edge of TCK" should be interpreted as "within a specified delay after the rising (falling) edge of TCK."

OK, so the TCK source is not the AVR, but an external source and functions asynchronously of the native AVR clock.

I wonder what the speed capabilities of the AVR JTAG system is?

Looking at JTAG ICE from ATMEL, it appears that the dongle is only a level converter, with the TCK from the host.

Quote:
5.4.1 Outputs
The JTAG ICE has implemented the following data output signals: TMS, TDI, TCK, [DBGRQ]. These signal are transmitted through the circuitry shown in Figure 5-4.
Figure 5-4. Level Converter Output

Unfortunately, using host software for TCK is problematic, as you can see from a simple study I did a while ago on the parallel port under Linux...

Quote:
A simple experiment to help identify characteristics of parallel port timing for programming and debugging of target hardware. Problems of cable failure or software defects are reported with open source and proprietary development platforms without consideration of erratic throughput.

Single trace mode of the parallel port D0-D7 while moving the PC mouse in a circle....

You can see it's a real mess! B0 is the primary 'clock'. This example is on a PII GNU/Linux Ubuntu box...

http://tinyurl.com/35k53w[/b]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Atmel JTAGICE is much more than a level shifter.

The data that propagates from the host (PC) into the JTAGICE "dongle" is nothing but a series of either USB or asynchronous serial commands encapsulated in high-level datagrams as defined in application note AVR060 (JTAGICE) and AVR067 (JTAGICE mkII/AVR Dragon).

In themselves, the packets sent from the PC to the JATGICE don't contain any information about which physical JTAG signals should transition to what level at which time. All those decisions are made independently within the JATGICE's embedded microcontroller, which interprets the packets to decide what operation to perform, and responds by bitbanging the relevant communication via TCK/TDO/TDI/TMS/etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lfmorrison wrote:
The Atmel JTAGICE is much more than a level shifter.

The data that propagates from the host (PC) into the JTAGICE "dongle" is nothing but a series of either USB or asynchronous serial commands encapsulated in high-level datagrams as defined in application note AVR060 (JTAGICE) and AVR067 (JTAGICE mkII/AVR Dragon).

In themselves, the packets sent from the PC to the JATGICE don't contain any information about which physical JTAG signals should transition to what level at which time. All those decisions are made independently within the JATGICE's embedded microcontroller, which interprets the packets to decide what operation to perform, and responds by bitbanging the relevant communication via TCK/TDO/TDI/TMS/etc.

Right, I didn't mean to make it seem that the JTAGICE wasn't important...but there is often some confusion for 'emulators' that don't have the datagrams, or the ICE component specific commands which are sometimes proprietary.

But JTAG TCK - it's not reliable in software from the host.

Do you know the actual propagation speed of TCK in the AVR JTAG logic? I'm sure it exceeds the system clock, as Lee pointed out earlier.