Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service
November 2005
 
BUILDING A SIMPLE AND EFFECTIVE TEST WITH
P&E MICROCOMPUTER SYSTEMS TOOLS
By Kevin Perreault

Overview

Product testing is a critical yet often complex and expensive process. Taking advantage of embedded processors with on-chip debug capability has made it easier to complete a simple internal test of a product. The following explains how you can take advantage of these capabilities to create your own product test. We’ll examine these four areas to improve your testing process:

  1. Use of Debug Mode (BDM) to control processor operation
  2. Application of P&E’s DLLs on a PC to make test applications which control the processor and run tests via debug mode
  3. Using the Processor to test as much of the board hardware as possible
  4. Creating a test fixture to add more complex test capabilities

1. In-Circuit Test and Debug Mode

Debug mode is available on most Freescale processors and allows complete control of processor operation, regardless of whether the processor has been programmed. Debug mode allows a controlling application to peek and poke memory from the viewpoint of the CPU. The application can load and run code, and send results back into the PC. Test applications can therefore use debug mode to perform tests of the target hardware. Such tests may also be enhanced with the addition of a custom test fixture.

By using debug functions, the test application can control on-chip and off-chip circuitry and then observe the operational results of these functions. An external test fixture can provide additional control and observation points, test circuitry, and also route product signals so that they may be easily tested. The product itself can be connected to other electronic devices to allow for a complete functional test while it is being controlled/observed via debug mode.

The primary goal is to test as much of the circuitry on the product as possible and, in the case of a failure, be able to identify the fault with as much precision as possible. The advantage of using debug mode is that the processor doesn’t need to be running application code for the test to run. The test will not be prevented from operating by a failure that may impede the final application from actually running in the product (e.g., a fault on address/data lines). In addition, it is significantly simpler to design a test application on the PC using debug mode than to build a test that will run only in the product. A PC test application can also record and display test results and be integrated with other test and control applications.

Return To Top

2. Controlling Debug Mode from a PC Application

P&E Microcomputer System’s UNIT library is a DLL-based driver on the PC. This library allows the user to create an application which fully controls the execution of an embedded Freescale processor via P&E’s hardware interfaces. The DLL's may be called from C or Delphi. Test applications may be created in any development environment that interacts with a Windows Dynamic Link Library. The DLL uses one of P&E’s many hardware interfaces to communicate via bit-shifted information to the processor’s debug port. The hardware being tested should have a debug connector or debug test points to allow connection of the P&E hardware.

The functions available in the UNIT library include: processor reset, read/write memory and peripheral registers, loading code, and execution control. These functions allow the test application to fully control the processor and to interact with other hardware that is connected to the processor.

Return To Top

3. Testing the processor and board hardware

This section lists the steps that P&E typically executes when creating test applications for its own hardware products.

Booting the processor

The first step is usually to reset the processor and then check to make sure it has entered debug mode. Reset is a standard call in P&E’s UNIT library. The test application resets the processor and then tries to read and write a CPU core register, in order to make sure BDM communication is active. Since the CPU registers are part of the core, they should be accessible if debug mode and the core processor are both operating properly. Failure at this stage is typically due to lack of processor power, a power pin or ground pin fault, no clock on the processor, or some critical failure on the debug lines.

Basic Memory Testing

For products which use external memory, the next step after reset is to test this memory for connection problems on the circuit board (shorts or opens). This test is done so that future tests may load and run code out of this memory. A memory test is relatively simple to perform because it is both fully controllable and observable. Any memory location may be written and then read back to make sure that the write/read operation occurred properly. The UNIT libraries include byte/word/long read and write routines. Typically the chip select configuration registers would be written to enable the external memory, and then the memory itself would be written/read. By choosing specific addresses and data values, all address and data lines may be tested in a very short period of time (as the test involves writing less than 0.1% of the memory on the device). An example of this may be seen at http://www.netrino.com/Articles/MemoryTesting/. Non-volatile flash may be tested similarly using P&E’s flash programmer, as described later in this document. This approach can also be used to evaluate on-chip RAM, Flash, or EEPROM.

Code Execution and MCU Timing Test

The next step is to test whether code will run on the processor itself. Generally, the code used in this stage does not interact with peripheral hardware on the board and is intended simply to test whether the processor can run code without failure. This involves disabling the watchdog, enabling RAM, loading a small looping kernel that counts into RAM, setting the PC to the start of this kernel, and then starting the processor running. The PC test application stops the processor a short time later. If the loaded kernel is actually counting and the program counter is still pointing somewhere in the loop, then the test was successful.

Also, by monitoring how long the processor was running (controlled by the test application), the value of the loop counter, and the number of cycles per loop, it is easy to determine the bus frequency of the processor. This is useful in order to ensure that the processor is running at the correct frequency, and that the oscillator has not gone into limp mode. Failure of the processor to run any code is usually an indication that there is a critical failure in the control/interrupt lines of the processor.

; ASM Code for ColdFire Processor Timing Test (test_cf.asm)


cal_1:  addi.l #1,d0     ; Increment D0 register once per loop

        bne.l  cal_1

        halt

Board Level Test

After we have tested a part it is shown here:

Once we know the processor can run code properly, it is time to reach out from the processor and begin testing the rest of the product. This next test is specific to the product itself, but the methodology is the same across different products. We analyze each component on the PCB to determine whether we can control its operation from the main processor, and also whether we can observe its operational result. The idea during design is to build a product which is both 100% controllable and 100% observable. For those components that we can control and observe, we write a test to determine whether they are operational. For those components that we can’t directly control or observe, we will use a simple test fixture to help us control and observe those components as necessary. The fixture may involve something as basic as connecting some signals to others, or may be more complex in that the fixture could have its own test hardware accessible to the processor.

To demonstrate one example of a test process, we will take a look at the way P&E tests, calibrates, and programs our Cyclone PRO product. The Cyclone Pro is shown here with an overlay indicating the functionality of the circuitry:

The modules of the Cyclone PRO are tested as follows:

Ethernet PHY and Connector:
The PHY chip is external to the processor and handles the transmission and reception of data on the Ethernet bus. Using memory writes in the processor, we configure the PHY for loop-back operation and then poke data into the device transmitter. If we receive the data back we know that the PHY is operating and its connection to the processor is good. We then set the PHY for normal mode and transmit a packet to a local PC, which responds in kind (it is running a test application). If we get the appropriate response packet we know that the magnetics and Ethernet connector are good as well.

RS232 Transceiver and Connector:
We can either send or receive data on the serial port, so we test it by using a little loop-back plug on the DB9 connector during test. This loop-back connection could also be built into the test fixture itself. If we can receive the data that we transmit, then we know that the connector and RS232 transceiver are good.

Compact Flash Buffers/Connector:
During test we have a Compact Flash card plugged into the Cyclone PRO unit. We load a small test application into the RAM of the processor which programs data into the Compact Flash card. The test is similar to the RAM test documented previously, and tests all address/data line connections through the compact flash buffers and connector.

USB Driver and Connector:
The USB port test requires interrupts to be running on the processor, so we load and run a small application in RAM which simply has code to enumerate USB properly when connected to a PC. The application is set to stop running when enumeration is complete. Before the test is started, the USB port is connected to a PC. If the test runs and properly stops, we know that it can communicate via USB to the PC, and that the transceiver and connector are good. We time this test in case the USB enumeration with the PC does not occur. The test application has the option of stopping or resetting the processor if the test times out.

Power & Clock:
These are tested when the processor is first connected. Without power the processor will not run and we won’t be able to connect to it. The clock is tested by measuring the bus frequency of the processor as detailed earlier. As an additional test, our test fixture connects the SPI port on the processor to a series of A/D chips in the fixture itself, which the processor uses (during test only) to measure different voltages within the Cyclone Pro product.

Custom Signaling:
This application-specific section is tested in several ways. First, several of the pin headers are actually output and input signals of the product with compatible signaling levels. On the test fixture, we route the outputs back to the inputs such that the processor can drive certain signals out and then read them back in. This validates both. Also, A/D converters on the test fixture are used by the processor to measure several output voltages on the Cyclone PRO itself. These A/D converters are controlled by the SPI port of the main processor, which is also connected to the test fixture.

Running test code in RAM

The process of running test code in RAM on the target processor is relatively straightforward. The UNIT library has a routine to load an S-record file (compiled/assembled test routine) into the processor’s RAM space. The loaded test routine should be written to complete a specific test, set a CPU register indicating success or failure, and then stop execution by entering debug mode (done via a special instruction on the processor - usually BGND or BKPT).

The PC test application sets the program counter to the start of the loaded routine and begins execution. The application then waits for the processor to re-enter debug mode when it executes the BGND/BKPT instruction. The PC test application then reads a CPU register to determine if the test was successful or not.

Programming flash from the test application

One common task that users want to perform is to program the flash of their target. This programming is performed by P&E’s CPROG command-line flash programmer (included with P&E’s standard flash programming software). This automated utility allows a binary object to be programmed into either internal or external flash that is connected to a Freescale processor. The standard Windows library allows a PC application (including one which uses the UNIT libraries) to call the flash programmer, wait for it to complete, and recover - whether or not there was an error. The CreateProcess() function is used to launch the programmer and the GetExitCodeprocess() function is used to check the result. P&E has a FAQ detailing how to launch the programmer from within a windows application at: http://www.pemicro.com/faqs/faq_view.cfm?id=28 .

Often the test application will test the hardware, launch the programmer to program the final application code into the processor’s flash, and then potentially run a functional test.

Return To Top

4. Inexpensive Test Fixtures

A test fixture may or may not be necessary, depending upon the complexity of the unit under test. A fixture allows additional circuitry or test connections to be added to the unit during the testing process. The fixtures that P&E builds are generally simple ones which add A/D converters to the processor’s SPI bus to allow the processor to read a series of internal voltages during the test process. Test probes connect the A/D converters to both the processor and the signals to be tested. Often the test fixtures that P&E uses also route certain hard-to-test signals back to unused processor input pins, so that their state may be observed during test. A picture of P&E’s Cyclone MAX test fixture can be seen here:

Test Probes

Test probes are available from several companies, including QA Technology (http://www.qatech.com). The material holding the test probes in place is a milled polycarbonate sheet which can be created in a standard machine shop. Precision is important because the size of the test pads on the product PCB generally allows for +/-15 mill tolerance (half of the diameter of the pad). To improve tolerances, data from the application that is used to design the product PCB can be exported to software such as AutoCAD, which can be used to define the exact locations of the drill points.

A large variety of probe point styles are available to connect to different types of test points. For example, a simple spear point can be used to connect to a surface pad, while a cup point can be used to connect to the end of component's lead. A picture of a spear-type point is shown.

The probes are inserted into sockets that can be soldered or wire-wrapped to a PCB which is permanently attached to the fixture. This PCB may contain additional test electronics and debug connectors.

Return To Top

Conclusion

The tools and methodologies provided here by P&E will help you reduce the complexity of product test. Using the increased capabilities described here will result in a more effective test process, affording you greater reliability and faster time to market.

For more information on how P&E products can help you, please visit the P&E website at www.pemicro.com.

Return To Top


© 2017 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement