Systems based around a central and versatile microcontroller or processor run the risk of putting all the proverbial eggs in one basket. When the CPU is the only brain on the board, it will often be the only device with test capabilities such as boundary-scan built in. While boundary-scan shines in small form factor systems, what happens when the CPU—the only component with test capability—is missing a crucial boundary-scan test function?

Even the best DFT practices may not catch all complications, and some problems—especially those related to high speed buses—are becoming more and more frequent. In this discussion, we’ll take a look at a case where complications prevented complete ICT & boundary-scan tests, paving the way for ScanExpress JET testing during prototype and production. This is a real case from a real customer—product names have been omitted for privacy.

The Problem
In our case, the embedded system used a popular applications processor in a small BGA package, eliminating probe access and the possibility of using ICT right off the bat. The PCB was part of a high-reliability product and would be used day in and day out in rugged environments—thorough structural and functional tests were not optional. The CPU had boundary-scan built-in, but there was a problem—this CPU did not include control of a particular memory clock signal—an essential component for boundary-scan testing of synchronous DRAM devices.

Figure 1 depicts a simplified diagram of the situation. Notice that the clock is not part of the boundary-scan chain—boundary-scan has no way of controlling the clock, making memory tests at best unreliable.

Boundary-Scan Memory Interface with a Free Running Clock
Figure 1: Diagram of Boundary-Scan Memory Interface with a Free Running Clock
The common practice of routing unused boundary-scan IO pins to provide a boundary-scan driver for a non-boundary-scan net was ruled out early since the memory clock pin was “free-running”, or always active at full speed. It was clear that an alternative test solution would be needed to complement the traditional boundary-scan tests.

The Solution
Luckily, Corelis’ ScanExpress JET (JTAG Embedded Test) solution was intended for just this scenario. JET utilizes the JTAG control port on modern CPUs to automatically create and execute functional tests for the CPU and surrounding peripherals at speed, filling the test coverage gap. JET was able to quickly and conveniently create tests for the system, including NAND Flash programming in addition to the standard system & memory interface tests. The new tests not only added structural coverage to the memory interface, but also provided at-speed, thorough functional tests—all while the product was still in the prototype stage.

Not only was JET able to extend testing capability above and beyond traditional testing methods, but it also proved to add significant time savings. Using ScanExpress JET with a Corelis JTAG controller reduced total programming time down from nearly twenty minutes to just under ten minutes when compared to the previous emulation-based Flash programming solution used by this customer—a huge amount of time over the life of the product.

Published On: November 12, 2010Categories: Corelis Boundary-Scan Blog, JTAG Boundary-Scan

Share This Story, Choose Your Platform!