One question that I often hear is: “What’s difference between JTAG Boundary-Scan Test and JTAG Emulation or a JTAG ICE?”
First off, these two methods share common functions such as: hardware bring-up, device programming and even some basic hardware test functionality. The big difference is that test systems are designed to do extensive hardware testing of circuit boards and ICE tools are predominantly used to debug hardware and firmware.
While the implementation is often different, the result is the same. Let’s take a look at both methods:
JTAG Boundary Scan Test
JTAG tools are extremely powerful and are an excellent way to do device programming and board testing. In Boundary-Scan mode the JTAG chain is essentially a serial shift register that runs throughout a device.
Reading and External Device Pins
Each external pin can be set to a state or have it’s state read by manipulating the internal JTAG state machine. If you want to read a pin, figure out how many bits to stuff into the serial register, set up the state machine and clock them through. When the shifting is done, you will have the value that you need.
Writing to External Device Pins
Conversely, for setting pins, you would load the pattern up, set up the state machine and shift the bits out until they reached the pins in question.
Testing Multiple Devices on a JTAG Chain
To allow for board testing, boundary-scan enabled chips are daisy-chained together. The TMS and TRST lines are shared by every device, while the TDI and TDO lines form the daisy chain connections. The result is one long scan chain.
By reading pins and clocking out data and by writing pins via JTAG, any pin on any JTAG enabled device can be easily tested. Of course, this description is greatly simplified. In reality there are ways to put devices in so called “bypass” mode allowing them to be skipped over and ignored.
Devices can also be placed in transparent mode allowing signals to be passed through them. This Pass-through mode along with adherence to design for test (DFT) rules allows devices that are off the scan chain to be tested.
Fault Detection and API Access
Using this scheme, JTAG Boundary Scan Test tools can detect opens, shorts and “stuck at” faults on a system under test.
Using APIs and macro language interfaces, even complex device like Ethernet transceivers can be tested at an electrical and a basic functional level. Finally, programmable devices like: FLASH Memory, CPLDs, and FPGAs can be programmed in-circuit.
JTAG Emulation or JTAG ICE
A JTAG Emulator or ICE typically uses JTAG as well. (Some devices, like the Freescale Coldfire family use a BDM debug interface, while others like the Freescale MPC555 use the NEXUS interface.)
Assuming that JTAG is used–as it is on a popular device like the ARM9 core–the intent is more typically for hardware and software debug and FLASH Programming as opposed to Test.
When used as an ICE, JTAG controls and runs the microprocessor. In test mode, the processor is typically not running. An ICE also uses JTAG to communicate with the processors internal resisters allowing them to be set or read by the tool.
Special Processor Registers Support JTAG Debug
With an ICE, special registers controlled by JTAG in the processor are used to support debug functions like: Step, breakpoint, stop, run, memory and register read and write. IN order to do complex operations quickly, the JTAG channel is often used to set up the processor and it’s peripherals to work with RAM and FLASH in the system. Once the system is set up, programs can be spoon-fed to the processor’s RAM by the ICE. This is very powerful, since it all happens before the system is up and running user code.
Feel free to ask questions of leave comments
Thanks
{ 5 comments… read them below or add one }
Hi,
nice article… but still i am not clear on the functionality diff od both of them. can you be specif to an operation of ICE and JTAG whic compliments each other.
one more thing how a jtag/ice programs the flash ?
thanks for your time to reply,
Hi,
JTAG ICE – Used to control the processor and RUN CODE on the target microprocessor. ICE allows you to load the code, set it, run it ,stop it, set breakpoints and in general debug the code.
JTAG Boundary SCAN Test – Uses JTAG to send and receive test patterns to devices on a board, can also be used to program devices. Is NOT used to load code or debug code on the target microprocessor. In fact does not even require a microprocessor in the circuit; can work with hardware logic (JTAG Cell enabled) only.
JTAG ICE programs FLASH by loading code to RAM on the system and causing the target micro to run this code. The code does the erase and programming of the FLASH. ICE can also do slow FLASH programming by “wiggling” address, data and control, lines from micro to the FLASH. This does not require working RAM (or code in RAM).
Hope that helps
Hi,
It’s very helpful article. But to understand precisely, I have two questions about them.
First , I understand that ICE is more complicated than JTAG Boundary SCAN Test. Does functionality of the ICE cover that of another? I mean, ICE can control/run processors, directly program programmable devices, and test JTAG Cell enabled hardware logic.
Second, this is about ICE devices working with processor(like ARM)-based FPGA board (like MultiICE). ICE device must understand architecture of target microprocessor and know where JTAG cells are placed exactly in the architecture. So the ICE device can control the processor using the JTAG SCAN Chain of the processor, FLASH, RAM, and the others.
Please confirm above two questions.
Thanks for your time to answer.
How the break point on my debugger can set the break point on the processor? What is the sequence of operations that the software (debugger) on my host computer to make the processor reach the break point??
Does the software inserts a breakpoint instruction while the processor is running?? In other words…does the debugger software tries to write an instruction on the processor while it’s running to force it to halt?? And if so..how the software debugger writes to memory while the processor is reading instructions from the same memory???
Hi Baher,
Great question.
The answer is it depends on the processor you are using and what you are trying to do.
For example most JTAG enabled chips support both hardware and software breakpoints in the chip.
As for how this works in practice, to set a software break, the debugger would write an illegal/breakpoint instruction into memory that will cause the processor to go to an exception vector (interrupt) when the code is run and the address is hit. The debugger needs to take over this interrupt and put in its own handler to process the breakpoint.
This method has a few issues in embedded programming:
It does not work on FLASH based code (unless you want to replace the code in FLASH which is slow on most debuggers).
It does not work if mmu translation is happening like with LINUX applications as many applications share the same code address.
It does not work if a boot loader or some other mechanism overwrites the breakpoint. For example if you put a software breakpiont at the RAM address for the start of the LINUX kernel it will not work since UBoot will load the kernel to this address and overwrite your breakpoint. This is why you would use a hardware breakpoint.
Hardware breakpoints are built in on-chip. They are typically set and cleared by accessing processor registers.
Usually they branch to an exception when they are hit and can be handled in the same way as the software breakpoint from then on.
Other things the debugger needs to do on the host side:
Track the address of code and functions so that the user can set breaks at source code level.
Keep track of the number of breaks in use since all systems handle only a finite number of breakpoints.
thanks
pat
You must log in to post a comment.