ROM Emulation Provides Functional Testing
You can substitute an emulator pod for a microprocessor-based PCB's boot ROM to avoid the drawbacks of hot-mock-up tests and the time and expense of implementing built-in-test techniques.
Jim McBride, LXE, Norcross, GA -- Test & Measurement World, 6/1/2000 2:00:00 AM
Traditional methods for testing microprocessor boards include hot-mock-up (HMU) and built-in-test (BIT). HMU testing is the easiest to implement—you place the microprocessor board into the end system and verify that it works. HMU test, however, provides little in the way of diagnostic capability. BIT, which uses hardware and software designed into the board itself, is a powerful technique for functional test.
In a typical implementation, designers place BIT software in nonvolatile memory on the microprocessor board; then, during test, a technician places a jumper on the board to initiate the test sequence. You gain access to test results and diagnostic information through a serial port. The drawback of BIT is that it requires a significant investment in hardware and software engineering during a PCB’s design.
What Is ROM Emulation? As an alternative, you might consider ROM emulation, an easy-to-implement method for testing microprocessor boards. During test, an emulator pod containing memory replaces the UUT’s boot ROM. You load a monitor program for the target processor into the emulator memory, and the monitor program runs when you boot the UUT.
The monitor program acts as an interface between the test program, written in a high-level language, and the emulator, which passes commands to the UUT microprocessor. The result is that the test engineer can control the microprocessor on the UUT through a test program written in a high-level language.
ROM emulation offers several advantages over other test methods:
• Emulation is conceptually simple. The emulator is basically a passive device that simply waits for the UUT’s microprocessor to fetch
commands.
• Emulation tests a UUT at full speed.
• UUT synchronization is automatic because the UUT microprocessor fetches commands from the emulator under the microprocessor’s own timing control.
Note that ROM emulators designed for testing differ from the traditional ROM emulators used for software development. Traditional ROM emulators run assembly code written by software developers for embedded applications; developers don’t need to burn new ROMs every time they change a line of code. Traditional emulators also provide breakpoints and other tools to assist engineers in debugging code. In contrast, the test ROM emulator is specifically designed to enable test engineers to test microprocessor boards.
The main difference is that the test ROM emulator uses a simple high-level command set rather than assembly-language commands. Emulator manufacturers (see “Representative Vendors of Test Equipment Having ROM Emulation Capabilities ”) write software drivers for each microprocessor type they support to translate between some high-level command set and the target microprocessor’s assembly language. Therefore, you can write test programs for many types of microprocessors using a supported high-level command set, thus eliminating the need to become proficient in the assembly language of each type of microprocessor you might encounter.
Command Sets for ROM Emulators Typical high-level command sets for ROM emulators contain the commands necessary to access memory and I/O ports on the UUT:
• write I/O,
• read I/O,
• write memory, and
• read memory.
In addition, the sets usually contain more complex commands designed to make the test engineer’s job easier:
• RAM test. This command performs a full-cell memory test of the UUT RAM.
•ROM checksum. This command is used to evaluate a checksum for any ROMs on the UUT.
Other diagnostic commands assist in troubleshooting kernel faults. These commands are particularly useful for isolating failures in boards that won’t boot:
• Bus test. This command forces data onto the UUT data bus to ensure that none of the bus lines are shorted or stuck. It runs before the UUT boots.
• Address trace. This command sets up the emulator to record each address from which the microprocessor fetches data or instructions during the boot sequence and helps to find address-bus faults.
•Chip-select detect . This command determines if the ROM received a chip-select signal during boot.
Most test ROM emulators can also run assembly-language code, a capability that’s necessary if a UUT must perform a real-time function that will not tolerate the delays inherent in high-level-language programs. Also, you can use assembly-language routines to perform complex UUT setups that would be time-consuming with high-level routines. To do this, you can often simply copy and reuse the setup code from the UUT’s boot ROM.
For the UUT to run the assembly code, the code must be placed in the UUT’s memory map. You can copy the code to the UUT’s RAM or to a user area in the emulator memory that resides in the UUT’s ROM’s address space.
a)
|
b)
|
| Figure 1. (a) A test ROM emulator (left) connects to a UUT (bottom) via the UUTs boot-ROM socket and reset and ground test points. (b) The emulator can become part of a complete board-test ATE system. |
|
| Figure 2. If your UUT’s ROM is soldered to the UUT, you must ensure that the PCB designers provide a means of temporarily routing the onboard ROM’s chip-select signal to the test emulator. |
|
| Figure 3. The board represented by this block diagram lends itself to a step-by-step test procedure in which a test emulator applies test signals in accordance with the board’s I/O- and memory-map values. |
To run the assembly code, issue a jump command from the emulator to force processor execution to branch to the location where the code begins. After the processor executes the code, the technician can reboot the UUT to allow the emulator to regain control.
Alternatively, you can place a jump command as the last line in the assembly code, so processing will begin at the entry point of the ROM emulator’s monitor program. In this way, the emulator regains control of the UUT without the need to reboot the system.
Connecting the ROM Emulator to a UUT An additional advantage of ROM-emulation-based testing is that it requires few modifications to the UUT. You’ll need to connect the ROM emulator to the UUT ROM and the UUT reset and ground lines. Typically, the ROM emulator pod plugs into the UUT ROM socket, and test points or a test connector can provide external access to the UUT reset and ground lines (Fig. 1).
Things get slightly more complicated when the UUT ROM (often a flash device) is soldered on the board. In this case, board designers must add a test connector (or test points) to the UUT to provide access to the ROM signals. They also must add a gate and control line to disconnect the chip-enable (CE) line from the onboard ROM and route it to the test connector. A typical solution is to bring all the ROM signals out to test pads and access them through a Pogo-pin interface (Fig. 2).
ROM Emulation for Functional Test When developing a functional test using ROM emulation, a test engineer must look at the UUT from the viewpoint of a software developer. The UUT is divided into functional blocks that are accessed through the memory and I/O maps. The ROM emulator reads from and writes to each device through each device’s memory or I/O interface.
Figure 3 is a block diagram for a microprocessor board that is to be tested using ROM emulation; the figure also shows the UUT’s I/O and memory map. “A Sample Test Plan,” p. 68, shows a basic functional test plan for this board. This test plan provides a comprehensive test of the UUT and is straightforward and easy for you to develop using ROM emulation.
Integrating ROM Emulation with ATE When selecting a ROM emulator, consider how you will integrate it into your testing environment. Emulators are available in three basic varieties:
• Stand-alone ROM emulators are available as a complete system for microprocessor board testing. These turnkey units are easy to use, but they do not integrate easily into ATE systems.
• ROM emulators are available as options with some commercial in-circuit/ functional testers. These units are well integrated as a part of a complete ATE system.
• ROM emulators are available as separate instruments with a standard interface bus such as ISA or PCI card. These units are designed for you to integrate into an ATE environment. They come with DLLs or instrument drivers so they can be accessed through standard, high-level programming languages (or test environments) such as C, VisualBasic, LabView, or ATEasy.
Emulator FeaturesIn addition to the basic command set, there are other features you should consider when choosing a ROM emulator:
• Make sure the emulator will support a range of microprocessors. Changing to a new microprocessor should require only a software update.
• Make sure the emulator supports a variety of ROM sizes and form factors such as DIP or PLCC packages. Ideally, you can use the same emulator pod with any package type with only a cable change.
| Representative Vendors of Test Equipment Having ROM Emulation Capabilities | |
|
Digalog New Berlin, WI 262-797-8000 www.digalogsys.comGenRad Westford, MA 978-589-7112 www.genrad.comGeotest Santa Ana, CA 888-837-8297 www.geotestinc.com |
Navatek Engineering Lake Forest, CA 949-588-2121 www.navatek.comInternational Test Technologies San Francisco, CA 800-200-0010 www.intertesttech.comWayne Kerr Woburn, MA 781-938-8390 www.waynekerr.com |
• It’s a good idea to choose a ROM emulator that supports logic levels other than just 5 V. Many newer microprocessors use 3.3 V or even lower voltages.
Although used primarily to test microprocessor boards, ROM emulation can also be used to test peripheral boards designed to plug into microprocessor boards. You plug the peripheral board into the host microprocessor board, which becomes part of the test fixture. The ROM emulator then connects to the host microprocessor board and tests the peripheral board by performing read/writes to control it.
ROM emulation is a powerful technique for functional testing of microprocessor and microprocessor peripheral boards. It is an easy-to- implement, comprehensive, and elegant test method that you should consider whenever you must develop tests for microprocessor boards. T&MW
Jim McBride
is a test engineer at LXE, Norcross, GA, working in product development for wireless data-communications equipment. He holds a B.S. degree in physics from Georgia State University and is currently working on an M.S.E.E degree at Mercer University.
E-mail: mcbride_j@LXE.com.
|
A Simple Test Plan Power-up 1. Using a programmable power supply, apply DC voltage to the power input of the board shown in Figure 3. 2. Measure VIN voltage and current. UUT Initialization 1. Boot UUT using reset line. 2. Verify that the ROM emulator has control of the UUT. Power Supply Status 1. Read the status of the 5V_OK and 12V_OK signals at I/O address 84HEX using the ROM emulator. RAM Test 1. Read and write to RAM 1 at addresses 80000HEX to 9FFFFHEX using the ROM emulator. 2. Read and write to RAM 2 at addresses A0000HEX to BFFFFHEX using the ROM emulator. 3. Read and write to RAM 3 at addresses C0000HEX to DFFFFHEX using the ROM emulator. 4. Read and write to RAM 4 at addresses E0000HEX to FFFFFHEX using the ROM emulator. UART Test 1. Set up the UART parameters by writing to I/O registers 60HEX to 6FHEX. 2. Apply an external loopback between TX and RX on the UART. 3. Write data to the UART output buffer at address 6FHEX using the ROM emulator. 4. Read data from the UART input buffer at address 6FHEX using the ROM emulator. ADC Test 1. Apply a DC voltage at the ADC external DC input. 2. Read the ADC at I/O port 80HEX using the ROM emulator. 3. Repeat for various ADC input voltages. —Jim McBride |
Signal management
11/01/2004Functional test: Back to basics
10/01/2004Tests keep tracking shipments
12/21/2007You can get there from here
05/31/2004
-
FLIR offers IR camera for under $3000
-
Don't let the economy compromise quality (Guest commentary)
-
Danaher speeds up restructuring, acquires life-sciences businesses
-
Agilent’s Cover-Extend technology eliminates need for physical test points for in-circuit test
-
So many combinations: Testing a switch-matrix board
View All Webcasts
