Re: [iPAQ] JTAG who?

On Wednesday, February 27, 2002, at 03:37 AM, jrlpop@mail.portland.co.uk
wrote:

> Sorry for this slight OT question: I'm not a newbie and I have lots of
> wierd knowledge I'll never get any use of, but I never heard of JTAG.
> Anyone with the knowledge please give a short summary for the curious.
> Is it a bus? A protocol? On what level?

It's the "IEEE Test Access Port and Boundary-Scan Architecture" (IEEE
Std 1149.1-1990, 1149.1a-1993). Here's the abstract:

"Circuitry that may be built into an integrated circuit to assist in the
test, maintenance, and support of assembled printed circuit boards is
defined. The circuitry includes a standard interface through which
instructions and test data are communicated. A set of test features is
defined, including a boundary-scan register, such that the component is
able to respond to a minimum set of instructions designed to assist with
testing of assembled printed circuit boards."

Nearly all SA-1110 designs expose at least four signals (clock, mode
select, data in, data out) which allow a development host to drive the
JTAG state machine in the processor (and other devices which may be
daisy-chained in the JTAG "loop"). There are 292 1-bit serial shift
registers ("scan cells") in the StrongARM which allow the host to set
and get the status of (almost) every pin on the package, which means
that the host can emulate certain simple behaviors. For example, static
memory interface bus transactions can be executed, albeit slowly,
without the processor actually running any local code.

The point of doing all this is to perform some basic sanity checking of
the component interconnects, and in the case of most low-volume
StrongARM designs, to program the initial firmware. (For high-volume
manufacturing, you'd just burn the flashes in a programmer prior to
placement on the board, and hope they don't get zapped by static
beforehand.) This interface has been invaluable on Spot for both
purposes (we use a DB25 parallel port interface similar to the one
specified for the Intel reference platform); I'm now writing a Python
tool to permit interactive/scriptable JTAG sessions for better hardware
testing. (Everyone already uses some variant of Intel's Jflash tool,
which is a miserable piece of code. Unfortunately, since it's written in
C, it's trivially quick, whereas I'm having to optimize the bejeezus out
of the Python version. =( )

The very short version for iPAQ users is, an exposed JTAG port on the
iPAQ would eliminate nearly all risk from Linux installation, since you
could always reprogram the bootldr. (This is, in fact, how I do all of
my bootldr development on Assabet and Spot.) You could even imagine
unburdening those hardy souls in iPAQ Valhalla by making "community JTAG
cables," which could be passed from user to user as needed.

-jd
Received on Wed Feb 27 15:22:47 2002