Power-On Self Test (POST) has been a basic staple for system level test since systems were first manufactured. POST traditionally comprised of a set of functional tests that would target key modules of a system that were able to be functionally separated from the whole of the system to try to verify that the circuit module was still functioning according to written requirements. In most cases, a failure of the functional test meant nothing more than the module did not perform as expected with little to no insight into what caused the test to fail (e.g., GO/NO-GO diagnostics). For field service calls, where a board was required to be pulled if a failure occurred, down time to diagnose where a failure occurred needed to be kept to a minimum. Unfortunately, functional testing was not able to isolate a circuit module down to a single board (e.g., Field Replaceable Unit (FRU)), but rather isolated a fault down to a set of boards. The craft operator would replace the entire set of boards (FRUs) to get the system back into operation. This let to a problem of No-Trouble-Found (NTF) or No-Fault-Found (NFF) conditions of boards while they were being tested at the Repair Depot. As boards become more complex, the cost associated with a board increases significantly. Thus, pulling out a board that is suspect is a costly inventory proposition and wastes testing resources at the Repair Depot that further increases the cost of maintenance of a product.
To improve the granularity of test coverage, more detailed functional tests may be written that target finer granularity of the system. Unfortunately, not all systems lend themselves to this partitioning for test. Further, to write a functional test that targets specific failure models is both time consuming and requires a special expertise in the circuit targeted by the test. Therefore, writing detailed functional tests for circuit boards tend to be cost prohibitive as market windows shrink and the overall life span of a product diminishes. To aid in the development of tests that provide a finer granularity of diagnostics, the use of Boundary-Scan technology is being introduced into the system as part of system test.
Boundary-Scan, or IEEE Std 1149.1 has been used since its inception in 1990 to provide a testing mechanism inside devices that aid in targeting structural or assembly type defects in circuit boards. The 1149.1 techniques are used extensively in the manufacturing process to verify that board assemblies have been built according to their design. Since 1149.1 targets the structure of the circuit and not the functional behavior, tests may be automatically generated from the design CAD data. The ability to automatically generate these tests significantly reduces the cost of test generation for a board. Further, these tests provide very precise test coverage metrics as to which parts of the circuit are tested and which are not. More importantly, the 1149.1 based tests are able to diagnose a failure down to a device pin and board net level giving the ability to isolate a failure to a single FRU instead of a set of FRUs. It is this latter case that may be leveraged to reduce the number of NTFs ending up at the Repair Depot for a system by implementing Boundary-Scan-Enhanced (BSE) POST in a system. Once the infrastructure is in place on a board, tests that were designed for manufacturing may be migrated to the system test environment directly or further constrained to eliminate the stimulation of signals that propagate off the board during testing. BSE POST would be run prior to or as an initial part of the boot process for the board. The simplest diagnostic results provided by BSE POST would be a PASS/FAIL indication or could be as detailed as identifying the failing device pin and net information.
To achieve Boundary-Scan-Enhanced POST, the design must provide an 1149.1 test controller on the board to be tested that is either under software control by a hosting processor or incorporated into a test co-processor in an FPGA, CPLD, or dedicated IC. The test controller hardware interface may be a dedicated device or may leverage 4 or 5 spare general purpose input/output (GPIO) pins on the hosting microcontroller. The additional hardware cost to support BSE POST, can range from $0 to $20 depending on the complexity of the test controller and the performance requirements. Generally, POST does not need a high performance interface that would be required for programmable logic device programming.
Some issues that need to be address are:
- The type of test actions that should be performed during POST
- The interface boundary between external test tools and embedded tooling
- Real-time diagnostic results vs. Off-line diagnostics from stored failure information
- What diagnostic resolution is required for POST?
- Formats of information passed from external test tools to embedded test tools
- What information should be reported?
- How does BSE POST integrate into the usual POST process?
- The value BSE POST brings to the POST process?
Moderator note: Edited list formatting