Home » Corelis Boundary-Scan Blog » JTAG Boundary-Scan » JTAG for Functional Test without Boundary-scan

JTAG for Functional Test without Boundary-scan

Introduction
We see a common theme with our JET application: users are looking for a solution
where ICT is limited by physical access, when optical and mechanical solutions
are not sufficient, and—an unfortunate case—when boundary-scan support is either
missing or limited in a critical area.

Now, JET is intended to function as either a compliment to boundary-scan
covering high speed and higher level functional tests OR as a standalone
product; in other words, the benefit of adding JET tests does not hinge on a
lack of boundary-scan. JET test techniques are useful whenever non-intrusive
board test is necessary. With all that said, boundary-scan limitations are a
definite driver in creating JET requirements and, to better understand these
requirements, let’s profile a JET supported CPU that we’ve seen great success
with in the past: the i.MX21.

i.MX21
The i.MX21 applications processor from Freescale includes an ARM926EJ-S core and
a host of peripherals, diagrammed below. While the diagram has a JTAG section,
it does not include a key bit of test capability information: the i.MX21
unfortunately does not have boundary-scan capability.





Figure 1: i.MX21 Multimedia Applications Processor (www.freescale.com)

There’s a JTAG port, but this processor does not support boundary-scan test.
This is something that often comes up when talking to our customers—aren’t JTAG
and boundary-scan synonymous? Not necessarily.

A particular processor might have a JTAG port for programming and debug without
including any boundary-scan capability. The TI MSP430 is a good example: it has
a JTAG port for programming the internal memory but no boundary-scan register (BSR).
We run into a similar case with the i.MX21—JTAG is included for debugging, but
there is no boundary-scan test capability available for non-intrusive structural
test.

Determining Boundary-scan Capability
If it’s not obvious from the documentation (where good search terms include “JTAG”,
“scan”, and “BSD”), check the website for a BSDL download—if there’s no BSDL,
that’s the first clue that a JTAG-capable devices does not have a BSR. It’s
always a good idea to check with your FAE or representative about a BSDL before
giving up, since many vendors do not make all BSDLs publicly available.

Additional Cases
Some devices may have a BSR, but not fully support boundary-scan in the way that
we usually expect. This includes the following cases:

Incomplete BSR – We’ve seen some devices include a BSR that covers only a
fraction of the device pins. The BSR may exclude a clock pin, some critical IO
pins, or in some extreme cases we’ve even seen memory interfaces completely
excluded. These devices will provide limited test coverage.

Limited I/O – Even in cases where all critical pins are covered by the BSR,
there are cases where the boundary-scan I/O implementation is limited. For
example, we’ve seen parts where the boundary-scan memory data interface is
output-only, preventing memory tests from functioning.

Shared Control Cells – Sometimes boundary-scan control cells will be shared
among multiple IO pins. This is OK in cases where those pins never need to be in
different input/output states, but sometimes—especially when doing cluster
tests—we need them to be in opposite states and a shared control cell simply
won’t allow this.

The classic example is memory data and address buses: the address bus needs to
be driving from the boundary-scan device to the memory at the same time the data
bus is switching between driving and sensing (to accommodate both write and read
modes). Since the data bus and address bus share controls, we can’t drive an
address and read data bus on the same test vector!

Using JTAG without the BSR
Even if no BSR is available, it’s not the end of the world—we can still use that
JTAG port and the CPU’s debug/emulation capabilities to run functional tests.
This is where ScanExpress JET shines: by adding in emulation-based functional
test, we can increase the amount of non-intrusive test coverage where there
would be no or very limited coverage otherwise.

JET is immune to BSR problems because it uses emulation instead of
boundary-scan—if the CPU can talk to the memory when it’s functional, then it
should be able to do so in debug/emulation mode. JET can then pick up the slack
on test coverage and even become the main test system in many cases.

Conclusion
If you have a CPU with limitations to testability either through boundary-scan,
ICT, or any other method, let us know! We’re always looking to add support for
more processors to ScanExpress JET.

Leave a Reply

Your email address will not be published. Required fields are marked *