JTAG and flash

JTAG (Joint Test Advisory Group) is a simple serial bit interface. It specifies a chip-testing access connection located on an IC between the external pins and the chip internals.

A JTAG device is just a bit-bang connection with four bits (TRST, TMS, TCK, TDI) to the device under test and one bit (TDO) from the device.

The devil lies in the sequencing of the bits, often wholly handled in software.

The interface is described in the IEEE 1149 standard, which is sold by IEEE

and thus not available for free in the Net.

The JTAG programming interfaces on programmable chips are manufacturer and chip-specific. The data source for these are the data sheets of the chips.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

There are two bits to a JTAG interface.

1) The TDI/TDO chain. You connect all the devices in a loop with TDI into the first device being driven by your controller (software/debugger/processor/whatever) and TDO connected to TDI of the next device. TDO of the last device then connects back to your controller. Each device has a shift register in it so that the controller can send out data and knows where in the chain it will end up. 2) TMS. To tell the devices what they are going to do with the data that has been shifted into them or what data to shift out of them each JTAG device has a state machine controlled by TMS.

What the devices do with he data is up to the manufacturer. Most use it to take control of the IO pins of the device to check the connectivity of the PCB. Some use it to program FPGAs or CPLDs and some use it for a debugger.

Colin

Alice,

This is NOT a flash chip! It is a PLD. BIG difference. You had my hopes up for a moment there. JTAG for Flash chips would be a God send for production/manufacturing....

JTAG for PLDs/FPGAs is quite commonly interfaced with an adapter you plug into your PC USB or serial port. Since JTAG interface is a standard, I would think that the only question is which software you need to run for the particular manufacturer....

Paul

If you have a flash chip connected to the bus of a processor with JTAG, you can program the flash.

Meindert

Thanks for the replies, I appologize about the flash error (instead of PLD). I have another question. If I had an ARM chip and an xscale chip, and I connected TDI/TDO (and the other jtag pins) to the correct places on the ARM chip, would the same jtag cable/device work on the xscale chip if they were connected to the proper pins? I'm confused if each jtag cable/device is chip specific (is a jtag device used to communicate with an arm chip is different than one needed to communicate with an xscale chip?)

TDO will not work correctly. TDO is an output from you Xscale or ARM or PLD. TDO must have only one driver.

Please check

for an introduction to JTAG including TAP.

TCK and TMS are input for all the devices.

TDI is an input for the first device on the JTAG chain. The TDO of the first device on the JTAG chain will be an input for the second.

The TDO going to your JTAG Emulator is the TDO of the last device on the JTAG chain.

You may see our JTAG Accelerator controller datasheet if you need more info on the JTAG interface.

Best Regards, Laurent

Alice,

No need to apologize... perhaps my tone came across wrong... I was expressing disappointment because a JTAG Flash IC would be really, really, really cool.

No. You *can* chain all the JTAG devices together by chaining the TDO of device #1 to the TDI of device #2, and so forth... BUT a word of caution. I have been involved on several board integrations where devices from various vendors did not 'play well' with each other. I'd recommend separate chains for each mfr--if you have the real-estate/luxury of more connectors and their costs.

I also would run separate JTAG chains for any SoC design for the debug/ internal microprocessor and the FPGA portion.

Speaking from experience...although I know it is not *supposed* to cause any problems.

Paul

I'm quite sure, Intel strata flash has a JTAG interface. Alternatively, you can download some flash programming code to the microprocessor and get it to do the work.

Look for the terms BYPASS and CHAIN. IIRC, One JTAG mode, BYPASS, is to reduce the 'skipped' device to a single FF, and you chain many JTAG devices - that's in theory....

You will find a few threads where the chain position matters, and some JTAG tools fail depending on position. This can be SW oversight, or sometimes bugs in the JTAG implementation - IC vendors tend to do chain testing late in their design flows :)

-jg

Alice

The JTAG spec does not define a connector pinout and everyone has done it differently. In particular programming a PLD is done once and does not require that much data and so the pinout that ALTERA hase chosen is very simple. However an ARM debugger would be interacted with constantly during software dev and might load several MBytes of code into the ARM. It therefore wants the JTAG interface to run as fast as possible and so the debugger manufacturer would choose a JTAG cable appropriately. It all comes down to whether the software can toggle TDI.TMS and CLK and read TDO to get what it wants. Early debugger software could not cope with anything else in the chain, more recent ones probably can but when engineers are bitten once they never forget. The only advice you will get is to use seperate chains. If the XSCALE and ARM rep say it can be done then you need to see it before you believe them.

Colin

I accidentally deleted Tim's reply---but in response,

No, the Intel strata does not have a JTAG interface.To my knowledge (and I've searched diligently--although it was a few short months ago) no Flash mfr provides a JTAG interface. I'd love for someone here to prove me wrong....anyone?

Thanks,

Bo

Oops. I beg your pardon. I think I had in mind the following paper which describes programming flash over JTAG. However, it uses the JTAG interface on a device connected to the flash (i.e. a CPU).

Program Intel® Flash Memory Using the IEEE 1149.1 (JTAG) Test Access Port ftp://download.intel.com/design/flcomp/papers/30827401.pdf

Surely this is just as useful though? When would you have flash that isn't connected to a CPU? You don't even have to download code to the CPU; you can simply hijack the CPU's pins (chip select, address and data bus) and do the flash programming from the host.

Flash could easily be connected to a PLD or FPGA for use in signal generation for example.

This doesn't sound too bad, but in the case where it's connected to a state-machine PLD or whatever, programming is still a royal pain. I encountered this on a Xilinx SoC design. Not exactly complicated, but sure did eat a lot of resources and time to get it working.

Bo

On Fri, 27 Jan 2006 15:12:03 -0600, "Bo" wrote:

I agree, Using JTAG is an extremely simple in concept. The problem is one is shifting out 1000's of bits to perform a relative simple task such as a single bus read. The tools for debugging this is expensive or non existant. Only one bit may be incorrect, and the only result one see, is that it is not working. Finding the specific sequence which is not working is not neccessaraliy difficult --- just extremely time consuming. Coupled with this, the JTAG documentation on most parts are so sparse, that it borders on non existant. A standard layer on top of JTAG would make life much simpler. Unfortunately the chances of that seems to be very small. The only flash devices I know of that has a JTAG interface was the PLD+Flash devices made by waferscale. They were bought out I think by ST a number of years ago. IMO, One thing that would help with debugging such code would be an (open source) JTAG state machine simulator library that can simulate a JTAG state machine, together with various register sizes etc. It should have a well defined API, and a nice user interface that shows the current state of the JTAG state machine, and levels of the pins etc. driven by the JTAG chain. If one could use captured data from a JTAG chain as well as self generated data to drive such a simulator, it would help in reverse engineer the various debug protocols used on CPU cores, and not properly (or not at all) published by the manufacturers.

Regards Anton Erasmus

Thanks, the replies have helped, but I still don't know which jtag device to use. I found a site where I can build my own arm9 jtag adapter

I see there is software that comes with it, but it looks like it's only for the ARM940 core. What software would I need to use to get it to work with the Altera PLD? Am I correct in my assumption that the arm9 wiggler would work if I have the right software and correctly connect the adapter to the pins?

You have tried here ?

-jg

I think you need to understand JTAG better.

The "wiggler" has no magic in it. Its just an interface to a serial chain of latchs and inputs.

Decoding the serial data is where that magic is.

So, yes the right software will do what you want.

The other shoe is how fast the decoding is done be the software. The faster and more sophisticated the harware interface is, the easier for the software.

Alteras website has free software for their PLDs.

donald

Look on Altera's site. They have schematics for a simple parallel dongle, and software to program their PLDs. A slightly more generic programming software is a so called JAM player. Altera and many other companies provide the means of generating JAM files, which can then be used to program the specific device using the JAM Player.

Regards Anton Erasmus

Checkout OpenOCD + Amontec JTAG Accelerator.

OpenOCD is a stable JTAG server written in a very nice structure. (open source):

- ARM7TDMI(-S) support

- ARM720t support

- ARM920t support

- LPC2xxx flash support

- CFI Flash support

- a telnet interface (for low-level debugging tasks)

- a GDB interface

- support for Wiggler-style PC parallel port interfaces

- support for FTDI FT2232C based devices

- support for the Amontec Chameleon?s JTAG Accelerator configuration - ...

JTAG Accelerator help you to speed-up the JTAG interface from an EPP parallel port. The specification of the JTAG Accelerator is public.

Regards, Laurent