ARP Hardware and Hardware Diagnostics Guide

Contents

	1.0: Hardware
	  1.1: System Controller
	  1.2: ICC Backplane
	  1.3: Timerbd
	  1.4: A/D
	  1.5: D/A
	  1.6: Digio
	  1.7: Counters
	  1.8: Indexer
	  1.9: Ozone Board
	2.0: Diagnostics
	  2.1: General Guidelines
	  2.2: SYSCON
	  2.3: SCDEBUG
	  2.4: BCKPLN
	  2.5: CARD
	  2.6: DIGITAL2
	  2.7: TMRTEST
	  2.8: DTOATEST
	  2.9: INDXDIAG

1.0: Hardware

For each board type, I would like to provide the following information: 
	What is the function of the board?
	What are the salient performance figures?
	What are the different configuration options?
	  What are the important addresses?
	  What are the jumper options?
	  Are mods required to the board? Where are they specified?
	What diagnostics are available?

1.1: System Controller

The System Controller, in its various revisions, provides the interface between the ISA bus of an instrument's computer and the "Subbus" for connection to the Interface Card Cage (ICC) and other in-house electronics.

Documentation currently available for the System Controllers consists of schematics (offline) and the Subbus Cable Definition

The diagnostic utilities which pertain to the System Controllers are syscon, scdebug, and bckpln.

1.2: ICC Backplane

1.3: Timerbd

1.4: A/D

1.5: D/A

1.6: Digio

1.7: Counters

1.8: Indexer

1.9: Ozone Board

2.0: Diagnostics

For each diagnostic utility, I would like to answer the following questions: 
	What hardware does it address?
	What kind of problems can it identify?
	Under what conditions can the utility be run?
	  While TM is running?
	  With the instrument connected?
	  With cards installed in the ICC?
	If a problem is identified, what then?
	  For example, if SYSCON fails, scdebug might well be the next step.

2.1: General Guidelines

By way of introduction, there are some common features of the diagnostic packages discussed here. With one or two exceptions, these diagnostics are designed to be run stand-alone. That is, they should not be run while data acquisition is underway. Some of the diagnostics require that any instrumentation be disconnected from the cards under test or that cards be removed from the ICC. Please make sure that you understand the rules for the diagnostic you plan to run before invoking it.

Our user-level data acquisition operations allow you to issue a simple command to cause data acquisition to begin on a node which is (possibly) different from your GSE. This is generally not the case with the diagnostics. While they can be run over the network, they must execute on the node connected to the hardware. There are several ways to accomplish this in QNX. If the flight node is 20, any of the following commands will cause card to be executed on node 20:

	//20 card
	on -n 20 card
	onnode 20 card
You may also wish to start a shell on the flight node so all subsequent commands will be invoked on that node:

	on -n 20 sh
I will briefly summarize each of the existing diagnostics with a more detailed description to follow.

2.2: SYSCON

syscon tests each function of the System Controller board. As the first link in the path to the instrument, this is always a good place to start. This diagnostic doesn't help much if problems are reported, in which case you will probably need to advance to scdebug.

2.3: SCDEBUG

scdebug is very much an interactive diagnostic. It performs a number of tests on the System Controller and attempts to identify particular problem areas. When a problem is uncovered, scdebug loops, continuously performing an action appropriate to facilitate hardware diagnosis of the problem. For example, if data is not being read back correctly from one of the latches, scdebug will repeatedly write and read the problem data so the bit values can be traced throughout the board.

2.4: BCKPLN

If syscon passes, bckpln is the next place to look. bckpln allows you to manipulate all of the computer-controlled signals on the subbus cable and the ICC backplane. It includes configuration options to allow it to be used with no more test equipment than a volt meter but includes functionality to obtain more detailed data if a scope is available.

2.5: CARD

card is the one diagnostic that can safely be run during data acquisition. Except for the "subbus debug" mode, it is a totally passive diagnostic, simply reading data values from A/D boards. At a quick glance, card can tell you whether your A/D boards are behaving properly. It is also useful for verifying raw data values when reading converted values off of a telemetry screen.

2.6: DIGITAL2

digital2 is similar to bckpln and scdebug in that it provides low-level control over all the digital command lines on all of the digital command boards. It should definitely be run with the instrument disconnected, for obvious reasons. With a digio board in the ICC, it is an excellent end-to-end diagnostic since it can write to latches on both sides of the data bus and read back the values. If it passes its initialization successfully, you can be assured the datapath to the ICC is sound.

2.7: TMRTEST

tmrtest provides a crude test of the functionality of the timer board (formerly known as the "System Board"). This is a pass/fail test, and is of little use in diagnosing a malfunctioning board. It does work effectively to disable the use of timers whose interrupts are not working.

2.8: DTOATEST

This diagnostic provides enough controls to fully exercise D/A converters. Tests for linearity, full scale calibration, slew rate and hysteresis are all possible.

2.9: INDXDIAG

This is a low-level diagnostic for the indexer boards along the lines of scdebug. For a higher-level workout, we have a complete data acquisition setup which provides all the high-level commands with a realtime display.

(c)1995 Norton T. Allen