Table of Contents

List of Figures

List of Tables

Section 1
Introduction

The AXAF-I CCD Imaging Spectrometer (ACIS) Science Instrument Software (SIS) was developed by the Massachusetts Institute of Technology, Center for Space Research (MIT-CSR) as part of the ACIS Digital Processor Assembly (DPA). The DPA resides on-board the Advanced X-ray Astrophysics Facility - Imaging (AXAF-I). The DPA Science Instrument Software is responsible for acquiring and processing image data from the ACIS CCD Imaging Spectrometer and transferring the processed data to the AXAF-I Command and Telemetry Unit (CTU), which is then responsible for sending the information to the ground. On orbit, ACIS is operated by its Science Operations Team (SOT).

1.1 Purpose

The ACIS Science Instrument Software User’s Guide describes the operation of the key functions of the instrument software.

1.2 Scope

This document applies to the detailed design of the ACIS DPA Science Instrument Software. It does not provide information for the Ground Support Software (GSS), which is maintained separately as part of the Electronic Ground Support Equipment (EGSE).

This document supplies information applicable to SDM05 from the original contract, and to DM29 from MM8075.1.

By mutual agreement, MSFC Software Management and Development Requirements Manual MM8075.1, which supersedes MA-001-006-2H, forms the basis for this document.

1.3 References

This specification relies on a set of existing documentation. The following table lists these documents.

Several topics related to ACIS Flight Software are covered in a series of online reports, available from “http://acisweb.mit.edu/pub/File.pdf”, where “File” is the third column of Table 1.2.

Section 2
Overview

2.1 Instrument Hardware Overview

Figure 2.1 illustrates the overall hardware architecture of ACIS.

RCTU - Remote Command and Telemetry Unit

This provides the command and telemetry interface between ACIS and the spacecraft.

PSMC - Power Supply and Mechanism Controller

This provides power to the ACIS Digital Processor Assembly (DPA), which contains the Back End Processors and Front End Processors, and to the Detector Electronics Assembly (DEA), which contains the CCD Video Controller Boards and two interface boards. It is also responsible for controlling the ACIS door, vent valves, etc. (not shown). All of the PSMC functions are controlled by discrete commands received from the spacecraft; no instrument software is involved.

BEP - Back End Processor

ACIS has two redundant Back End Processors, responsible for the overall control of the instrument, including command and data handling. Although both BEPs are usually powered at the same time, only one BEP is active at a time.¹ Each BEP is powered by a separate side of the PSMC DPA Power Supply.

FEP - Front End Processor

ACIS has 6 Front End Processors that are responsible for acquiring digitized image data from the CCD Video Controllers, and for detecting candidate X-ray events from these images. For a normal science observation, data from each CCD used for the observation is processed by any one of the 6 FEPs (NOTE: it is possible, however, to have more than one FEP process data from the same CCD). FEPs 0, 1, and 2 are powered by A-side of the PSMC DPA Power Supply, and FEPs 3, 4, and 5 are powered by the B-side of the supply. In order to process data from 6 CCDs simultaneously, both sides of the PSMC DPA Power Supply must be on.

11th Board

This is the primary interface board for the Detector Electronics Assembly. It contains power switching logic for the DEA Video Boards, a Focal Plane temperature controller, and some housekeeping logic. These components are powered by the A-side of the PSMC DEA Power Supply. This board also contains a set of relays used to switch power on the video boards to the current PSMC DEA Supply. Unlike the DPA only one side of the PSMC DEA Power Supply may be on at a time.

12th Board

This board is a backup interface board for the DEA. It is identical to the 11th board except that it does not have the power-switching relays, nor does it have the housekeeping logic. This board is powered by the B-side of the PSMC DEA Power Supply.

Video Boards

ACIS has 10 DEA Video Boards. Each board is hard-wired to a particular CCD (see diagram for the mapping). Each video board contains a sequencer (loaded by the BEP) that is used to transfer charge within the CCDs. Each also contains digitization circuits to convert the analog CCD data into a digital form, which is then fed to the FEPs.

The ACIS Mongoose processors are all configured by hardware to use little-endian” byte ordering. For example, the 32-bit value 0x12345678 (decimal 305419896) is stored as bytes in RAM as follows:

By convention, bits within a word are numbered with the least-significant bit as bit number 0. This is consistent with the usage in the “MIPS Programmers Handbook” (see Table 1.1.) Unless otherwise specified, all signed values use two’s complement representation.

2.2 Instrument Software Overview

The ACIS Instrument Software runs on two types of processors within the system: the Back End Processor (BEP) and the set of Front End Processors (FEP). The BEP loads its software either from EEPROM or from the uplink command channel. Once up and running, the active BEP can enable power to the FEPs and to video boards within the Detector Electronics Assembly (DEA), and load software into the FEPs via shared memory, and into the video processors using serial digital interfaces.

The BEPs run a single-processor preemptive, multi-tasking kernel that allows the BEP to be performing more than one task at a time. For example, it can process science data, while acquiring DEA housekeeping data, while performing a memory dump (BTW: This is a very useful feature when trying to diagnose certain classes of problems). The telemetry produced by the BEP is organized into data packets, which appear in the “Software Serial Data” portion of the telemetry stream (IP&CL mnemonic 1TSERXT). Each packet is preceded by a 32-bit synchronization pattern, and contains a length field indicating the number of words in the packet. This allows telemetry produced by the several tasks running on the BEP to be merged into the telemetry stream (for example, memory dump telemetry packets may be mixed in with science event data packets).

Table 2.1 lists the BEP’s tasks, grouped according to their priority (highest priority, 51, is first, and lowest priority listed, 55, is last. Tasks with the lowest priority number have the highest run-time priority). In contrast, each FEP runs a single main thread, with a single interrupt handler to count the arrival of images produced by the DEA. The FEPs are only commanded by the software that runs on the active BEP. This single thread performs the high-performance portion of the science data processing, and polls its shared memory interface for requests from the BEP.

The shared memory interface was designed to permit the BEP to copy entire FEP bias maps into telemetry packets while simultaneously processing X-ray events, but this behavior caused FEP firmware to lock-up at times of high event rates. Software patches (buscrash, buscrash2) to prevent this have since been installed in the BEP, but it is still possible to command the BEP to dump the contents of a FEP processor’s memory to telemetry, e.g., for diagnostic purposes (see Section 3.6.1.3), provided the FEPs are not processing CCD frames at the time.

2.3 Commands and Telemetry

ACIS is commanded via its Remote Command and Telemetry Unit (RCTU). This unit provides various types of commands and telemetry. The ACIS hardware is commanded via high-level pulse commands to the ACIS Power Supply and Mechanism Controller (PSMC) and by 16-bit serial digital commands to the ACIS hardware serial port. In addition, commands to the ACIS software are contained within a series of 16-bit serial command words, known as command packets, which are addressed to the ACIS software serial port. For the purposes of this document, “Hardware commands” will refer to either high-level pulse commands addressed to the PSMC, or serial digital commands addressed to the DPA hardware serial port. “Software commands” will always refer to command packets addressed to the ACIS software serial port.

The ACIS hardware provides engineering telemetry that is read by the spacecraft and placed in fixed places within the spacecraft telemetry stream. The ACIS software produces telemetry as a stream of 32-bit words, packed and placed into the spacecraft telemetry stream allocated for ACIS science telemetry. These packets may or may not be separated by a variable number of fill bytes (0xb7), placed into the stream by the ACIS hardware when a packet is not being transferred.

For details on the content and format of the ACIS hardware commands and telemetry, refer to the ACIS Instrument Protocol and Command List (MIT-CSR 36-01410). For details on the content and format of the ACIS software command and telemetry, refer to the ACIS IP&CL Software Structure Definitions (MIT-CSR 36-53204.0204). For convenience, these definitions are summarized online in “acisweb.mit.edu/acis/ipcl”.

In this document, all commands to send to ACIS will be written in the syntax accepted by the bcmd command, a PERL script that translates ASCII input into a stream of binary commands and headers suitable for repackaging, e.g., through the SOT/ACIS Command Generation Software (SACGS) functions to create entries for the ACIS command tables used by the Observatory Control Center (OCC), or through sendCmds to send to the ACIS engineering unit. The bcmd functions are illustrated in Appendix B. This and other EGSE commands are listed in Appendix D and more fully described in on-line manuals and in the “ACIS Test Tools” document MIT-CSR 36-55001 referenced in Table 1.1. bcmd commands are written in structured ASCII text with optional comments, as illustrated in the following example:

The contents of all telemetry packets output by the BEP will be shown in this document in the format output by the ltlm command whose function is to read BEP packet streams and translate them into ASCII. The “start” command in this example will be acknowledged by ACIS with the following telemetry packet:

The names of UNIX commands and ACIS patches will be italicized and those of ACIS parameters will be shown in monotype. Input to bcmd will be colored brown and output from ltlm will be green. The names given to packets, commands, and their subfields are standardized across the ACIS ground system. Packets and their internal arrays are also given numerical indices, as in the following example:

where comments begin with “#” and, in this document, “...” implies that less important lines have been omitted for clarity, especially in the first 4 fields of each packet: synch through sequenceNumber.

This document contains many examples of “keyword = value” pairs, either passed to bcmd or output from ltlm and psci. We shall use two dots to indicate that a value will lie within a specified range, e.g., “fepId = 0..5”, and three dots to indicate an array of values, e.g., “fepCcdSelect = n₀...n₅”, to represent integers n₀, n₁, etc.

Section 3
Instrument Maintenance Activities

This section describes the various activities used to maintain the ACIS instrument software.

3.1 Starting the Software

This section describes how the ACIS instrument software is started. Before reading this section, the reader should familiarize themselves with the discussion in Table A.1 in Appendix A of the internal status flags in each of the two ACIS Back End Processors (BEPs).

A BEP can boot in one of five modes, as determined by the values of three bits in its Status Register, two of which, BOOT_MOD and WARM_BOOT, are set by ground command and the third, WDOGRST, is set when a “watchdog timer” expires, usually the result of some anomalous condition. See Table A.1 for details.

^* Ignore leaves the patches in I-cache memory, but ignores them. Delete deletes them from I-cache and doesn’t apply them; Apply leaves them in I-cache and applies them.

The BEP tests the three hardware bits in the order shown, i.e., if BOOT_MOD is 1, it will perform an Uplink Boot; otherwise it will test WDOGRST and WARM_BOOT and proceed accordingly. The implications of these various modes will be examined in the following sections.

3.1.1 Back End Processor Power-On

This section describes how to power-on a BEP in the ACIS Digital Processor Assembly (DPA). A BEP must be powered up for the instrument to receive commands.

Description

On ACIS, there are two Back End Processors, (BEPs), a Side-A processor and a Side-B processor. The Side-A BEP is powered by the Side-A DPA Power Supply in the PSMC, whereas the Side-B BEP is powered by the Side-B DPA PSMC. Each BEP is powered by issuing a PSMC enable command to the appropriate side, followed by a power-on command to that side. See Table 3.1 and Table B.5 in Appendix B.3 for lists of PSMC power commands. When powered, the BEP hardware and software will perform a power-on boot (see Section 3.1.3.1).

Since Side-A of the PSMC also supplies power to three of the Front End Processors (FEPs 0,1 and 2) and the Side-B PSMC supplies power to the remaining three FEPs (3, 4 and 5), both BEP processors are normally powered at the same time. However, only one BEP may be “active” at a time. At power-on, the Side-A BEP is the “active” BEP, while the Side-B BEP’s processor is held in a reset state and its external I/O logic is inactive. See Section 3.1.2 for a description on how to select the active BEP and for warnings concerning FEP power when switching between BEPs. See Tables 3.2 and B.2 (in Appendix B.2) for lists of commands affecting BEP status.

NOTE: If BEP-B is powered up, and BEP-A is not already powered, BEP-B will not be the selected BEP, and the serial digital telemetry and bi-level telemetry from the DPA will float. Lab experience has shown that the floating lines tend to a logical ’1’. See Section 3.1.2 for the procedure to activate BEP-B.

Commands

Table 3.1 lists the commands issued to power-on the BEPs. See Section 3.2 for commands to power-off the DPA’s BEPs. Also, see Section 3.1.3 for commands needed to enable and power on and off the Detector Electronics Assembly.

---

Table 3.2: Power On Command Sequence

Mnemonic	Command Type	Description
Power Up DPA Side-A Power Supply
1DPPSAEN	Pulse to PSMC Side-A	Enable (but don’t power on) the PSMC DPA Side-A
1DPPSAON	Pulse to PSMC Side-A	Power-On the PSMC DPA Side-A Power
Power Up DPA Side-B Power Supply
1DPPSBEN	Pulse to PSMC Side-B	Enable (but don’t power on) the PSMC DPA Side-B
1DPPSBON	Pulse to PSMC Side-B	Power-On the PSMC DPA Side-B Power

---

---

Table 3.3: Power On Engineering Telemetry

While the BEPs are off and PSMC disabled

After a pair of PSMC DPA Enable commands have been issued

After a pair of PSMC DPA Power-On commands have been issued

Mnemonic*	Telemetry Type	Value	Description
1DPPSAX	Serial Digital	0	Verifies that the DPA A-side Power Supply is disabled.
1DPPSBX	Serial Digital	0	Verifies that the DPA B-side Power Supply is disabled.
1DPPSA	Serial Digital	0	Verifies that the DPA A-side Power Supply is off.
1DPPSB	Serial Digital	0	Verifies that the DPA B-side Power Supply is off.
1TSERXT	SW Serial Digital	undefined	The software serial digital telemetry out of a BEP while powered off is undefined, however lab experience shows the interface almost always floats to 1’s, giving 8-bit data values of 0xff
1STAT[0..7]ST	HW Bi-level	undefined	The bi-level telemetry of the BEP when powered off is undefined, however, lab experience shows the interface almost always floats to 1’s.
1DPPSAX	Serial Digital	1	Verifies that the DPA A-side Power Supply has been enabled
1DPPSBX	Serial Digital	1	Verifies that the DPA B-side Power Supply has been enabled
1DPPSA	Serial Digital	1	Verifies that the DPA A-side Power Supply has been turned on.
1DPPSB	Serial Digital	1	Verifies that the DPA B-side Power Supply has been turned on.
1TSERXT	SW Serial Digital	fill = 0xb7	Once a BEP is powered and enabled (side-A defaults to enabled), the hardware places a fill pattern into the software serial telemetry stream. This fill pattern appears whenever the software is not transmitting telemetry packets.
1STAT0ST	Bi-level: bits 0-3	variable	When the BEP is first powered, the software sets the bi-levels to 0xf. As the system boots, it walks the bi-levels through a series of values so that if the instrument gets “stuck”, the ground can tell where. The bi-level value sequence is described in more detail in Section 3.1.3 and Section 3.1.4. Once running, the Flight Software’s Housekeeping Task updates these bits to indicate the current state of the instrument.
1STAT1ST		variable
1STAT2ST		variable
1STAT3ST		variable
1STAT4ST	Bi-level: BEP Id	0 (BEP-A)	If BEP-A is powered on first, it will be, by default, the selected BEP and drive the bi-level to 0.
1STAT5ST	Bi-level: CPU Not Reset	1	Since, by default, BEP-A is not held in a reset state when first powered, the BEP will drive this bi-level to a 1.
1STAT6ST	Bi-level: FIFO Not Full	1	After a power-on, the BEP’s command FIFO is reset by the hardware, and therefore will not be full, but instead is empty.
1STAT7ST	Bi-level: FIFO Not Empty	0

---

* Hardware commands and telemetry mnemonics are described in the ACIS Instrument Protocol and Command List (see Table:1.1.)

Engineering Telemetry

The following telemetry items in the engineering portion of the telemetry stream indicate when power is applied to the BEPs. The following assume that BEP-A is being powered first.

Science Telemetry

When a BEP has power, and the software is not transmitting any telemetry packets, the hardware supplies a single-byte fill pattern, 0xb7 (hexadecimal). Once the software is initialized after a power-on, it outputs a BEP Startup Message telemetry packet, and then approximately once every 64 seconds outputs a BEP Software Housekeeping telemetry packet. The Startup Message packet is described in more detail in Section 3.1.3. The Software Housekeeping packet is described in more detail in Section 3.4.3.

---

Table 3.4: Power On Science Telemetry

  

Tag Field	Value	Description
After the PSMC DPA Power-On command has been issued
If BEP-B is to be made active, a select command must also be issued (see Section 3.1.2)
TTAG_STARTUP	–	After the BEP software is initialized, it issues a BEP Startup Message packet.
TTAG_SW_HOUSE	–	Once running, the flight software emits 1 software housekeeping packet every 64 seconds or so.

---

Warnings

1.

Power Reset of Tables
A power-on will reset the state of the all hardware within ACIS, and reset all internal software structures. Any code, tables and data loaded into RAM will be lost.

2.

Power Reset of Uplink Flag
If the instrument was in a “load-from-uplink” state prior to being powered-off, the state of “load-from-uplink” flag will be lost. When the instrument is subsequently powered on, it will load code from its EEPROMs and execute the loaded code.

3.

BEP Select Confusion
If BEP-B is powered on and selected while BEP-A is off, and then BEP-A is powered on, both BEPs will be selected and will attempt to drive the telemetry interface. This will not hurt the hardware, but will make software telemetry impossible to understand. A “Select BEP” command to choose either A or B at this point will solve the problem.

3.1.2 Selecting which BEP is active

This section describes how to select which BEP should be active, and drive the interface hardware.

Description

By default, after a power-on, both BEP-A and BEP-B will assume that the active BEP is BEP-A. To select BEP-B, one must explicitly issue a hardware serial digital command to select it. In order to avoid confusion, and reduce the possibility of problems, it is recommended that a select command be issued whenever one or both BEPs are first powered on. (NOTE: see Warnings concerning FEP power when selecting BEPs). Whenever a BEP is de-selected, its processor is held in a reset state and the software on the BEP is halted. If the BEP is then selected, the reset is released, and the BEP software will proceed to boot and run.

Commands

The following are the commands issued to select a particular BEP.

---

Table 3.5: BEP Selection Commands

  

Select BEP-A

Select BEP-B

Mnemonic	Command Type	Value	Description
1BSELICL	HW Serial Digital	v=0	Select BEP-A by issuing the Select BEP command with data bit 0 (v) set to 0.
1BSELICL	HW Serial Digital	v=1	Select BEP-B by issuing the Select BEP command with data bit 0 (v) set to 1.

---

Engineering Telemetry

The currently selected BEP is indicated by a bi-level in the engineering telemetry (see Table 3.6).

---

Table 3.6: Selected BEP in Engineering Telemetry

  

When BEP-A is the selected BEP:

When BEP-B is the selected BEP:

Mnemonic	Command Type	Value	Description
1STAT4ST	Bi-level: BEP Id	0	If BEP-A is selected, this bi-level will have a value of 0.
1STAT4ST	Bi-level: BEP Id	1	If BEP-B is selected, this bi-level will have a value of 1. NOTE: If the active BEP is powered off at the PSMC, all bilevels will float to ‘1’, which may lead to confusion under some conditions.

---

Science Telemetry

If the chosen BEP is not already selected, then the select command releases the BEP’s reset line, causing the instrument software to load and run. Depending on the state of the BEP’s Boot Modifier Flag at the time of the select command is received, the instrument software’s bootstrap loader will either (a) load code from EEPROM (see Section 3.1.3) and will produce its standard Startup Message telemetry packet, and subsequent Software Housekeeping telemetry packets, or (b) will load code from a series of software serial command packets (Section 3.1.4), which may or may not produce any science telemetry, depending on what code is loaded and run.

Warnings

1.

BEP already selected
If the BEP is already selected, it will not be re-booted.

2.

BEP not already selected
If the BEP is not currently the selected BEP, it will be held in a reset state. Once selected, the BEP will behave depending on the most recently received “halt bep” or “run bep” command (i.e. the newly selected BEP with either start in a reset state or reboot accordingly).

3.

Both BEP-A and -B are selected
If BEP-A is powered on, or power-cycled while BEP-B is selected and running, BEP-A will assume that it is selected. This will cause contention and confusion on the telemetry interface. To correct the problem, re-issue the most recent select command after powering on BEP-A. To avoid the problem, issue halt bep and select bep a commands prior to powering on BEP-A.

4.

Neither BEP-A nor -B are selected
If BEP-A is powered on while BEP-B is powered off, and is then told that BEP-B is selected, no BEP will be driving the interfaces.

5.

FEPs may be held “on”
The BEP-A and BEP-B can both be commanded to enable and disable power to the FEPs. If both BEPs are powered and the previously selected BEP has left power enabled to some of the FEPs, the currently selected BEP will not be able to power-off those FEPs. This state is not harmful for the hardware, but may lead to confusion in subsequent observations. It will stay this way until either the previous BEP is made active again and commanded to power down those FEPs, or the PSMC is commanded to cycle the power on that BEP and its 3 associated FEPs. Therefore, be very sure to power down all FEPs before switching BEPs. See Section 3.3.2 for more detail.

3.1.3 Loading from EEPROM

Each ACIS Back End Processor is capable of loading its software either from its Read-Only-Memory, or from its uplink channel via software serial commands. This section describes the former.

3.1.3.1 Power-On Boot

Description

When a Back-End Processor (BEP) is powered on and selected, it executes a bootstrap loader residing within its Read-Only Memory (EEPROM). A special EGSE cable was required to enable the “Electrically Erasable and Programmable” function of this memory, and was removed prior to launch. This loader copies the bulk of the instrument software from the EEPROM into the BEP’s RAM, and transfers control to the loaded code. The loaded code detects that the instrument has been started by a power on and as a result takes the following actions:

1.

Copies the bulk of code and initialized data from EEPROM into I-cache and D-cache RAM.

2.

Resets the Patch List to “empty”.

3.

Copies Parameter Blocks (Te, Cc, 2d, 1d, Dea) from EEPROM into RAM (see Appendix I).

4.

Copies Bad Pixel and Column Maps from EEPROM into RAM.

5.

Copies Huffman Tables from EEPROM into RAM.

6.

Copies System Configuration Settings from EEPROM into RAM.

7.

Issues a Startup Message telemetry packet.

8.

All DEA Video boards will be powered off (as per the default EEPROM System Configuration Table settings).

9.

All Front End Processors (FEP) will be assumed to be powered off (as per the default EEPROM System Configuration Table settings). Note that after a power anomaly, the operator cannot assume that all FEPs are unpowered and must explicitly power on all FEPs and then command them to their desired states.

10.

Focal Plane temperature will be reset to its default EEPROM System Configuration Table value.

Commands

To power on and run Side-A BEP:

IP&CL syntax	bcmd syntax	Command Description
1DPPSAEN	enable dpa a	Enable Side-A DPA Power Supply
1DPPSAON	poweron dpa	Power-On Side-A DPA Power Supply
1BSELICL(v=0)	select bep a	Select Side-A BEP ensuring no contention with BEP-B.

To power on and run Side-B BEP:

IP&CL syntax	bcmd syntax	Command Description
1DPPSBEN	enable dpa b	Enable Side-B DPA Power Supply
1DPPSBON	poweron dpa b	Power-On Side-B DPA Power Supply
1BSELICL(v=1)	select bep b	Select Side-B BEP

Engineering Telemetry

Command Verifiers

1DPPSAX	0..1	Reports if DPA Power Supply A is enabled
1DPPSA	0..1	Reports if DPA Power Supply A is on
1DPPSBX	0..1	Reports if DPA Power Supply B is enabled
1DPPSB	0..1	Reports if DPA Power Supply B is on
1STAT4ST	0	indicates BEP-A is selected,
	1	indicates BEP-B is selected
		(NOTE: See Warnings in Section 3.1.2)

Boot Bi-level Sequence

LED_BOOT_RESET	(1,1,1,1)	BEP has just reset
LED_RUN_PATCH	(1,0,0,1)	Resetting patch list
LED_RUN_STARTUP	(1,0,0,0)	After an initial 64 second wait, the BEP’s Software Housekeeping task will alternate the bi-levels between two values every 64 seconds indicating whether or not a science run is in progress, and that the BEP was not restarted due to a watchdog reset. If a science run is not in progress, the bi-levels will alternate between:
LED_RUN_IDLE_A	(0,1,1,0)
LED_RUN_IDLE_B	(0,1,1,1)

If a science run is activated, the bi-levels will change to:

LED_RUN_SCIENCE_A	(0,1,0,0)
LED_RUN_SCIENCE_B	(0,1,0,1)

Science Telemetry

Startup Message from Power On Boot

bepStartupMessage[n] = {
synch	= 0x736f4166	# Packet synch word
telemetryLength	= 7	# Packet length in words
formatTag	= 8	# TTAG_STARTUP
sequenceNumber	= n	# Packet sequence number
bepTickCounter	= n	# (n < 10) BEP interrupt clock value
version	= 11	# BEP software version in EEPROM
lastFatalBepTickCounter	= n	# BEP interrupt count at last fatal error
lastFatalCode	= n	# Stored BEP interrupt code (see Table 3.15)
watchdogFlag	= 0..1	# if 1, SEU or hardware error
patchValidFlag	= 0..1	# if 0, SEU or hardware error
configFlag	= 0..1	# if 0, SEU or hardware error
parametersFlag	= 0..1	# if 0, SEU or hardware error
warmBootFlag	= 0..1	# if 1, SEU or H/W error
}

Software Housekeeping

swHousekeeping[n] = {
...
formatTag	= 10	# TTAG_SW_HOUSE
startingBepTickCounter	= n	# Starting BEP timer value
endingBepTickCounter	= n+640	# Ending BEP timer value
statistics[0] = {
swStatisticId	= 0	# SWSTAT_VERSION
count	= 1	# Number of reports
value	= 11	# Most recent reported value
}
statistics[1] = {
swStatisticId	= 3	# SWSTAT_TIMERCB_INVOKE
count	= 640	# Number of reports (~10 per second)
value	= 0	# Most recent reported value
}
}

Warnings

1.

Power-On Boot is always a Cold Boot
A power-on boot resets the BEP’s hardware flags, such as the Warmboot flag, and the Load-from-Uplink flag, making it impossible to perform a Warm Boot or Load-from-Uplink Boot using just a power-on command sequence. See Section 3.1.4 for a description of how to perform a Load-from-Uplink Boot, and Section 3.1.3.3 for a description of a Warm Boot.

2.

“As-launched” settings (including temperature control)
All Patches are lost and all Parameter Blocks, System Configuration Settings, and Huffman Compression Tables will be reset to their “as-launched” values (see Appendix I). Note: This affects power-consumption of the instrument, the focal-plane temperature control set point, and sets all 12-bit Analog to Digital Converter (ADC) channels reported in DEA housekeeping to 8-bit (coarse) mode.

3.

Memory Decay
Don’t count on any unused portions of BEP or FEP memory remaining intact. The powered-off static RAM memory will “decay” over time.

4.

See Warnings in Section 3.1.2

5.

“Stuck” Bi-level Values
The initial boot bi-level sequence will change faster than the sample rate of the telemetry system. Unless something goes wrong, don’t expect to see every code in the sequence as the instrument comes up. However, if the bi-level values “stick” to the following values for more than one science telemetry frame, or codes persist that are not listed, there is probably a problem with the instrument or command sequence to the instrument:

LED_BOOT_RESET	(1,1,1,1)	BEP has just reset
LED_RUN_PATCH	(1,0,0,1)	Copying patches or resetting patch list

If the following bi-level code “sticks” for more than 64 seconds, there may also be a problem:

LED_RUN_STARTUP	(1,0,0,0)	Starting the multi-tasking executive

In addition, software patches may set the bi-levels to special values in order to signal to Chandra’s On-Board Computer that some action should be taken. Currently, the following patches use special (unique) combinations:

Patch	Mnemonic	Value	Meaning
txings	LED_BOOT_SPARE1	(1,1,0,1)	The threshold crossing detector has tripped
deahktrip	LED_BOOT_SPARE2	(1,1,1,0)	One or more DPA temperature channels has exceeded its red limits

3.1.3.2 Cold Boot

Description

Cold Boots are performed in order to reset and re-initialize a BEP into an “as-launched” state, without resorting to cycling the power. In order to perform a cold boot, the desired BEP must be powered-on, and selected, with its Load-from-Uplink flag cleared (default condition after power-on), and its Warmboot flag cleared (default condition after power-on). It then must receive a BEP Halt command, followed by a BEP Run command. This will cause the BEP CPU to start executing the loader in its EEPROM. From then on, the boot process of the BEP appears just as a power-on boot. The loader and startup software will reset the Patch List, and reload the default tables from EEPROM.

Like a Power-On boot, a cold boot of the BEP:

1.

Copies the bulk of code and initialized data from EEPROM into I-cache and D-cache RAM

2.

Resets the Patch List to “empty”

3.

Copies Parameter Blocks (Te, Cc, 2d, 1d, Dea) from EEPROM into RAM (see Appendix I)

4.

Copies Bad Pixel and Column Maps from EEPROM into RAM

5.

Copies Huffman Tables from EEPROM into RAM

6.

Copies System Configuration Settings from EEPROM into RAM

7.

Issues a Startup Message telemetry packet

8.

All DEA Video boards and Front End Processors will be powered off (as per the default EEPROM System Configuration Table settings)

9.

All Front End Processors (FEP) will be powered off, as per the default EEPROM System Configuration Table settings, unless held on by the other BEP (see Section 3.3.2)

10.

Focal Plane temperature will be reset to its default EEPROM System Configuration Table value

Commands

IP&CL syntax	bcmd syntax	Command Description
1BMODIBM (v=0)	set bootmodifier off	Enable boot from EEPROM mode
1WRMBTSB (v=0)	set warmboot off	Enable cold boot mode
1RSETIRT (v=1)	halt bep	Stop the active BEP
1RSETIRT (v=0)	run bep	Restart and reboot the active BEP

Engineering Telemetry

Boot Bi-level Sequence (for detail, refer to Engineering Telemetry in Section 3.1.3.1)

LED_BOOT_RESET

LED_RUN_PATCH

LED_RUN_STARTUP

LED_RUN_IDLE_A

LED_RUN_IDLE_B

LED_RUN_SCIENCE_A

LED_RUN_SCIENCE_B

Science Telemetry

∙ Startup Message

bepStartupMessage[n] = {
...
formatTag	= 8	# TTAG_STARTUP
bepTickCounter	= n	# (n < 10) BEP interrupt clock value
version	= 11	# BEP software version in EEPROM
lastFatalBepTickCounter	= n	# BEP interrupt count at last fatal error
lastFatalCode	= n	# Stored BEP interrupt code (see Table 3.15)
watchdogFlag	= 0..1	# =1 if watchdog timer expired
patchValidFlag	= 0..1	# * =0 if patch list invalid
configFlag	= 0..1	# * =0 if config table invalid
parametersFlag	= 0..1	# * =0 if pblocks invalid
warmBootFlag	= 0..1	# =1 if BEP warm booted
}

NOTE: if any of the 3 starred fields is ‘0’, suspect a BEP hardware error or single-event upset (SEU) or telemetry corruption.

∙ Software Housekeeping

swHousekeeping[n] = {
...
formatTag	= 10	# TTAG_SW_HOUSE
startingBepTickCounter	= n	# Starting BEP timer value
endingBepTickCounter	= n+640	# Ending BEP timer value
statistics[0] = {
swStatisticId	= 0	# SWSTAT_VERSION
count	= 1	# Number of reports
value	= 11	# Most recent reported value
}
statistics[1] = {
swStatisticId	= 3	# SWSTAT_TIMERCB_INVOKE
count	= 640	# Number of reports (~10 per second)
value	= 0	# Most recent reported value
}
}

Warnings

1.

A Cold Reboot may occur on receipt of a BEP Select Command
If a BEP is running, i.e., not in the RESET state, and the other BEP is selected, the latter will immediately reboot in the mode determined by the values of its Load-from-Uplink, Watchdog, and Warmboot flags. For this reason, prior to switching BEPs, it is good practice to command the active BEP into the RESET state before selecting the other BEP.

2.

“As-launched” settings (including temperature control)
All Patches, Parameter Blocks, System Configuration Settings, and Huffman Compression Tables will be reset to their “as-launched” values (see Appendix I). Note: This affects power-consumption of the instrument and the focal-plane temperature control set point (see Section 3.3.6 and Appendix E).

3.

DEA Power-Up Issues
See Warnings #4 and #5 to Section 3.1.3.3 and Section 3.3.6.

4.

Preserved Memory
Unused portions of BEP memory will remain intact.

5.

“Stuck” Bi-level Values
The initial boot bi-level sequence will change faster than the sample rate of the telemetry system. Unless something goes wrong, don’t expect to see every code in the sequence as the instrument comes up. However, if the bi-level values “stick” to the following values for more than one science telemetry frame, or codes persist that are not listed, there is probably a problem with the instrument or command sequence to the instrument:

LED_BOOT_RESET	(1,1,1,1)	BEP has just reset
LED_RUN_PATCH	(1,0,0,1)	Copying patches or resetting patch list

If the following bi-level code “sticks” for more than 64 seconds, there may also be a problem:

LED_RUN_STARTUP	(1,0,0,0)	Starting the multi-tasking executive

3.1.3.3 Warm Boot

Description

A Warm Boot is used to reset a BEP’s hardware, re-load its code and data from EEPROM and install its patch list while attempting to maintain the already loaded configuration tables and parameter blocks. A Warm Boot retains the BEP’s Patch List, Parameter Blocks, etc. To issue a Warm Boot, the BEP must be powered on and selected, with its Load-from-Uplink flag de-asserted, but its warmBootFlag and its watchdogFoot flags bothflag in an asserted state. Upon receipt of a Halt BEP command followed by a Run BEP command, the BEP hardware will reset and invoke the loader software in its EEPROM. This loader copies the bulk of the instrument software from the EEPROM into the BEP’s RAM, and transfers control to the loaded code. The loaded code detects that the instrument warmBootFlag flag is asserted, and installs the Patch List nodes, overwriting the code and data areas specified by the nodes with the data stored in the patch nodes. The startup software then issues a bepStartupMessage telemetry packet.

A Warm Boot of the BEP:

1.

Copies the bulk of code and initialized data from EEPROM into I-cache and D-cache RAM.

2.

Installs the patches, overwriting code and data specified by the nodes in the Patch List with the data contained in the Patch List nodes.

3.

Issues a Startup Message telemetry packet, indicating the integrity of the patch list, parameter blocks and system configuration table. NOTE: Since the system configuration table controls the focal-plane temperature and FEP and DEA power settings, if the table has been corrupted, the startup code will restore the default system configuration table from EEPROM into RAM, overwriting the corrupted copy.

4.

The initialization code for the DEA will reset the DEA Interface Controller board. This will have the effect of powering off the video boards. Within a few seconds, however, the System Configuration Task will restore power to those boards indicated in the preserved system configuration table (i.e. those boards that were on prior to the warm boot, will be re-powered, provided the configuration table checksum is valid (see Warning #4, below).

5.

The BEP will also issue a hard reset to the DEA (PULSE_DEARST), which will cause its A-to-D converters to recalibrate and the focal plane temperature controller to reactivate. For details, see Warning #4 of Section 3.3.3.

6.

The hardware reset of the BEP will cause a reset of the Front End Processors (FEP), but won’t reset the FEP power settings. FEPs that were powered prior to the reset will remain powered, but will be held in reset state until a science run is started, or until they are powered off via subsequent cold boots or “Change System Configuration” commands (see Section 3.3.2).

Commands

IP&CL syntax	bcmd syntax	Command Description
1BMODIBM (v=0)	set bootmodifier off	Set the Bootmodifier flag off
1WRMBTSB (v=1)	set warmboot on	Set the Warmboot flag on
1RSETIRT (v=1)	halt bep	Halt the active BEP
1RSETIRT (v=0)	run bep	Restart the active BEP

Engineering Telemetry

Boot Bi-level Sequence (for detail, refer to Engineering Telemetry in Section 3.1.3.1)

LED_BOOT_RESET

LED_RUN_PATCH

LED_RUN_STARTUP

LED_RUN_IDLE_A

LED_RUN_IDLE_B

LED_RUN_SCIENCE_A

LED_RUN_SCIENCE_B

Science Telemetry

∙ Startup Message

The following packet is received after a successful warm boot. If valid patches had been loaded, they will typically set the version field to a value denoting the patch level (see column “Ver” of Table F.2). Otherwise, version will be 11, the value set from the EEPROM code.

bepStartupMessage[n] = {
...
formatTag	= 8	# TTAG_STARTUP
bepTickCounter	= n	# n < 10 or SEU or H/W error
version	= n	# ≠11 indicates patched or SEU or H/W error
lastFatalBepTickCounter	= n	# BEP interrupt count at last fatal error
lastFatalCode	= n	# Stored BEP interrupt code (see Table 3.15)
watchdogFlag	= 0	# = 1 if watchdog boot or SEU or H/W
patchValidFlag	= 0	# = 0 if patch list corrupted
configFlag	= 0	# = 0 if config table corrupted
parametersFlag	= 0	# = 0 if parameter blocks corrupted
warmBootFlag	= 1	# = 0 if SEU or H/W error
}

∙ Software Housekeeping

swHousekeeping[n] = {
...
formatTag	= 10	# TTAG_SW_HOUSE
startingBepTickCounter	= n	# Starting BEP timer value
endingBepTickCounter	= n+640	# Ending BEP timer value
statistics[0] = {
swStatisticId	= 0	# SWSTAT_VERSION
count	= 1	# Number of reports
value	= 11	# or patched or SEU or H/W error
}
statistics[1] = {
swStatisticId	= 3	# SWSTAT_TIMERCB_INVOKE
count	= 640	# Number of reports (≈10/second)
value	= 0	# Most recent reported value
}
}

If an error is encountered restoring DEA video board power then expect an additional statistics item (see below) in the housekeeping packet, where the value field reports the video board ID (0..9) in its most significant 16 bits and the internal DEA error code (see Table B.9 in Appendix B.4) in its least significant 16.

statistics[2] = {
swStatisticId	= 53	# SWSTAT_DEABOARD_ERROR
count	= n	# Number of reports
value	= v	# v = (boardId << 16) | deaErr
}

Warnings

1.

Warm Reset via the BEP Select command
If an un-selected BEP is selected, its Load-from-Uplink is de-asserted, but its Warmboot flag is asserted, the BEP will perform a warm boot.

2.

Retained Parameter Blocks
All Patches, Parameter Blocks, and Huffman Compression Tables are retained.

3.

Retained/Corrupted System Configuration
The System Configuration Table will be retained if its checksum is intact. If corrupted, however, the System Configuration Table will be overwritten by the default contained in EEPROM.

4.

Power-cycled DEA Video Boards
If the System Configuration Table is intact, the DEA Video boards that were powered prior to the reboot will be reset. If this is the first reboot since the PSMC last powered-up, the DEA interface board may not have been fully initialized (see Section 3.3.3). A second BEP reboot will ensure that it is.

5.

Cycled Focal Plane Temperature Control
If the System Configuration Table is intact, the DEA focal-plane temperature control set point will be set to 0 (due to the interface board reset), and then to the value it had prior to the reset.

6.

Reset FEPs
If the System Configuration Table is intact, FEP boards that were powered prior to the reset will remain powered, but will be held in a reset state.

7.

Preserved Memory
Unused portions of BEP memory will remain intact.

8.

“Stuck” Bi-level Values
The initial boot bi-level sequence will change faster than the sample rate of the telemetry system. Unless something goes wrong, don’t expect to see every code in the sequence as the instrument comes up. However, if the bi-level values “stick” to the following values for more than one science telemetry frame, or codes persist that are not listed, there is probably a problem with the instrument or command sequence to the instrument:

LED_BOOT_RESET	(1,1,1,1)	BEP has just reset
LED_RUN_PATCH	(1,0,0,1)	Copying patches or resetting patch list

If the following bi-level code “sticks” for more than 64 seconds, there may also be a problem:

LED_RUN_STARTUP	(1,0,0,0)	Starting the multi-tasking executive

Certain software patches also set software bilevels to special values so that the Chandra On-Board Computer can detect them and take some preset action. For details, see Warning 5 on Page 37.

3.1.3.4 Watchdog Reset

Description

When a BEP’s watchdog timer expires, the hardware sets a watchdog-reboot flag and issues a hardware reset. This may be caused by a task lockup in the BEP, or by a trapped fatal error condition, in which the recovery code uses the watchdog timer to reset the BEP. Once the BEP reboots, the loader in the BEP’s EEPROM is invoked. If the Load-from-Uplink flag is de-asserted, the loader copies code and data from EEPROM into RAM, and invokes the loaded startup software. The startup software checks the state of the Warmboot flag, and if asserted, it performs a warm-reboot sequence, except that it skips the step that installs the patches. If the Warmboot flag is de-asserted, the boot-sequence is identical to that of a cold-reboot (see Section 3.1.3.2). The ground can detect the occurrence of a Watchdog reboot via the Startup Message telemetry packet, and via the bi-level telemetry items.

A Warm Watchdog Reset of the BEP:

1.

Copies the bulk of code and initialized data from EEPROM into I-cache and D-cache RAM.

2.

Skips the installation of the patches (NOTE: Although the patches aren’t applied to the code and data in RAM, the patch list will remain intact).

3.

Issues a Startup Message telemetry packet, indicating that there was a watchdog reboot, and indicating the integrity of the patch list, parameter blocks and system configuration table. NOTE: Since the system configuration table controls the focal-plane temperature and FEP and DEA power settings, if the table has been corrupted, the startup code will restore the default system configuration table from EEPROM into RAM, overwriting the corrupted copy.

4.

The initialization code for the DEA will reset the DEA Interface Controller board. This will have the effect of powering off the video boards. Within a few seconds, however, the System Configuration Task will restore power to those boards indicated in the preserved system configuration table (i.e. those boards that were on prior to the warm boot, will be re-powered).

5.

The hardware reset of the BEP will cause a reset of the Front End Processors (FEP), but won’t reset the FEP power settings. FEPs that were powered prior to the reset will remain powered, but will be held in reset state until a science run is started, or until they are power-cycled via a pair of “Change System Configuration” commands (see Section 3.3.2).

Commands

None (although the crash may be the result of an earlier command).

Engineering Telemetry

Boot Bi-level Sequence

LED_BOOT_RESET	(1,1,1,1)	BEP has just reset
LED_RUN_PATCH	(1,0,0,1)	Copying patches
LED_RUN_STARTUP	(1,0,0,0)	Starting the multi-tasking executive

After an initial 64 second wait, the BEP’s Software Housekeeping task will alternate the bi-levels between two values every 64 seconds indicating that no science runs are in progress, and that the BEP was restarted due to a watchdog reset:

LED_WD_IDLE_A	(0,0,1,0)
LED_WD_IDLE_B	(0,0,1,1)

If a science run is activated, the bi-levels will change to:

LED_WD_SCIENCE_A	(0,0,0,0)
LED_WD_SCIENCE_B	(0,0,0,1)

Science Telemetry

If the Watchdog expiration is due to a caught Fatal Error, the BEP will issue a Fatal Error Message telemetry packet, (provided the processor is still capable of forming and queueing the request), and then force a watchdog timer expiration:

∙ Fatal Message

fatalMessage[n] = {
...
formatTag	= 8	# TTAG_FATAL
bepTickCounter	= n	# BEP tick on detection of error
fatalCode	= n	# BEP interrupt code (see Table 3.15)
fatalValue	= n	# meaning depends on fatalCode
}

∙ Startup Message

bepStartupMessage[n] = {
...
formatTag	= 8	# TTAG_STARTUP
bepTickCounter	= n	# n < 10 or SEU or H/W error
version	= 11	# or patched or SEU or H/W error
lastFatalBepTickCounter	= n	# BEP interrupt count at last fatal error
lastFatalCode	= n	# Stored BEP interrupt code (see Table 3.15)
watchdogFlag	= 1	# or not watchdog or SEU or H/W
patchValidFlag	= 0	# = 0 if patch list corrupted
configFlag	= 0	# = 0 if config table corrupted
parametersFlag	= 0	# = 0 if parameter blocks corrupted
warmBootFlag	= 0..1	# = 0 if (coldboot) or 1 (warmboot)
}

∙ Software Housekeeping

swHousekeeping[n] = {
...
formatTag	= 10	# TTAG_SW_HOUSE
startingBepTickCounter	= n	# Starting BEP timer value
endingBepTickCounter	= n+640	# Ending BEP timer value
statistics[0] = {
swStatisticId	= 0	# SWSTAT_VERSION
count	= 1	# Number of reports
value	= 11	# or patched or SEU or H/W error
}
statistics[1] = {
swStatisticId	= 3	# SWSTAT_TIMERCB_INVOKE
count	= 640	# Number of reports (≈10/second)
value	= 0	# Most recent reported value
}
}

If an error is encountered restoring DEA video board power then expect an additional statistics item (see below) in the housekeeping packet, where the value field reports the video board ID (0..9) in its most significant 16 bits and the internal DEA error code (see Table B.9 in Appendix B.4) in its least significant 16.

statistics[2] = {
swStatisticId	= 53	# SWSTAT_DEABOARD_ERROR
count	= n	# Number of reports
value	= v	# v = (boardId << 16) | deaErr
}

Warning

1.

Cold Watchdog Boot
If the Warmboot flag is de-asserted when the watchdog timer expires, the system will perform a cold boot, resetting the patch list, parameter blocks, bad pixel maps, etc. See Warnings in Section 3.1.3.2.

2.

Warm Watchdog Boot with No Patches
If the Warmboot flag is asserted when the watchdog timer expires, the system will perform a warm boot, except the patch list will not be installed. This could possibly raise compatibility issues with the retained tables, if format changes were introduced that relied on the patches being installed, or worse, a hardware problem work-around not being installed. Also, consider Warnings in Section 3.1.3.3.

3.

Power off in-use FEP
The most common causes of Watchdog resets in the lab have been (a) bad patches, and (b) FATAL_INTR_FEP_BUS_ERROR fatal errors due to accessing a FEP when its power is off. This can happen if one powers off a FEP while it is being used in a science run.

4.

Startup Message Info
In the Startup Message of the current version of the instrument software, the lastFatalCode field contains the BEP tick counter of the most recent Fatal Error Message.

5.

Recovery from Watchdog Boot
To recover from a Watchdog reset while preserving loaded patches, assuming the Patch List is not the cause, issue a Halt BEP/Run BEP command sequence to cause a normal Warmboot of the BEP.

6.

No looping Watchdogs
The hardware prevents looping Watchdog resets from locking up the instrument. After an initial Watchdog reset, the hardware prevents subsequent watchdog timer expirations, including those caused by a software Fatal Error, from resetting the BEP. An intervening commanded reset (or power-on reset), is required to reenable watchdog resets.

3.1.4 Loading from Uplink

Description

The Load-from-Uplink feature of ACIS allows a maintainer to load arbitrary software into a Back End Processor using the software serial-digital command channel. In order to load the BEP, one must first assert the Load-from-Uplink flag, and then reset the BEP (Halt BEP/Run BEP). The hardware transfers control to the loader software in the BEP’s EEPROM. The loader detects that the Load-from-Uplink flag is asserted, and waits for a “Start Upload” command packet followed by zero or more “Continue Upload” command packets. Once the entire load is copied from the uplinked packets into the BEP’s RAM, the loader invokes the loaded software. Once running, the loaded code has control of the instrument, and is responsible for all subsequent software command processing (if any) and telemetry production (if any).

If the loader receives an unrecognized command packet, it will discard the packet, and re-start the load, waiting for an initial “Start Upload” command packet.

If the loader receives a new “Start Upload” command packet in the middle of an existing load, the loader will stop the current load (leaving what was already copied into RAM intact) and start the new load. This behavior can be used to perform scatter loads into RAM (see Section 5.9).

Commands

IP&CL syntax	bcmd syntax	Command Description
1BMODIBM (v=1)	set bootmodifier on	Set the Bootmodifier flag on
1RSETIRT (v=1)	halt bep	Halt the active BEP
1RSETIRT (v=0)	run bep	Restart the active BEP

∙ Start Uplink

Begin by issuing a start command, which has the following content in bcmd format:

start n uplink loadAddress totalCount executeAddress {
word1 word2 ...
}

where a totalCount of 32-bit words are to be loaded into BEP memory starting at loadAddress and then executed, starting at executeAddress. If the number of words actually specified, i.e., word1, word2, etc., is less than totalCount, the BEP will not reboot but wait to expect additional start or continue commands.

∙ Continue Uplink

continue n uplink {		# CMDOP_CONTINUE_UPLOAD
word1 word2 ...
}

Once totalCount words have been loaded, either from start or continue, BEP execution will begin at the most recently supplied executeAddress. Once the program has been loaded and started, it is responsible for processing subsequent software serial commands (if any).

Engineering Telemetry

Boot Bi-level Sequence

LED_BOOT_RESET	(1,1,1,1)	BEP has just reset
LED_BOOT_UPLINK_WAIT	(1,1,0,0)	Waiting for “Start Upload” packet
LED_BOOT_UPLINK_COPY	(1,0,1,1)	Waiting for “Continue Upload” pkts
LED_BOOT_UPLINK_EXECUTE	(1,0,1,0)	Calling loaded program

Any further usage of the bi-levels is the responsibility of the loaded program.

Science Telemetry

Once the program has been loaded and started, it is responsible for all science telemetry (if any).

Warning

1.

Uses of Load-from-Uplink
Although Load-from-Uplink is a useful diagnostic feature, building loads requires detailed knowledge of the instrument, DPA hardware, and the ACIS software development environment. Transmission of load-from-uplink commands does not require much knowledge beyond that described in this document, but act of building and understanding the effects of programs that use the Load-from-Uplink feature requires knowledge beyond the scope of this document. It is expected that only the ACIS software maintenance team will build programs that use this feature. However, it is possible that this team may request routine uplink loads to perform some types of ACIS maintenance activities.

2.

State of Instrument after a Load-from-Uplink
The state of any on-board stored parameter blocks, tables, etc., is completely up to the loaded program(s). Some programs may corrupt the state of the instrument, whereas others may leave the instrument in the previous state.

3.

Watchdog Timer Maintenance
Once a program is loaded from the uplink channel and begins execution, it has up to 3 seconds to reset the BEP’s watchdog timer. Once running, it is the loaded program’s responsibility to maintain the timer (NOTE: If the watchdog timer expires, it will reset the BEP. It will not reset the BEP a second time until the BEP receives either a commanded reset (Halt BEP/Run BEP) or power-on reset).

3.1.4.1 Boot Duration

In the case of a Boot from Uplink (see Section 3.1.4) the boot takes as long as needed for the instructions and data to be sent to the active BEP in startUpload and continueUpload command packets. Otherwise, it generally takes 0.3 seconds to copy the contents of EEPROM to D-cache and I-cache, apply patches and begin executing.

3.2 Halting the software

This section describes how the ACIS instrument software is halted.

3.2.1 BEP Power-Off

This section describes how to power-off the ACIS Digital Processor Assembly (DPA) Back End Processors (BEP).

Description

One method of stopping the ACIS software from running is to power-off the “active” BEP. This can be accomplished by issuing a power-off command or a disable command to the PSMC responsible for the active BEP (see Section 3.1.2 for a discussion on selecting a BEP). The recommended method is to first issue the “power-off” command, followed by the “disable” command, however, just issuing the disable command has the same affect.

Commands

The following are the commands issued to power-off the BEPs. See Table 2.1 for commands to power-on the DPA’s BEPs. Also, see Section 3.3.3 for commands needed to enable and power on and off the Detector Electronics Assembly.

---

Table 3.7: Power Off Command Sequence

  

Mnemonic	Command Type	Description
Power Off Side-A BEP
1DPPSAOF	Pulse to PSMC Side-A	Power-Off (but don’t disable) the PSMC DPA Side-A
1DPPSADS	Pulse to PSMC Side-A	Disable the PSMC DPA Side-A
Power Off Side-B BEP
1DPPSBOF	Pulse to PSMC Side-B	Power-Off (but don’t disable) the PSMC DPA Side-B
1DPPSBDS	Pulse to PSMC Side-B	Disable the PSMC DPA Side-B

---

Engineering Telemetry

For a description of the state of the Engineering telemetry when power is off versus on, refer to Table 3.2.

Science Telemetry

When the power is off on a BEP, the science telemetry is undefined, although experience in the lab indicates that it tends to float to logical ’1’.

Warning

1.

Lose all loaded parameters and tables
When a BEP is powered off, it loses all loaded parameter blocks, system configuration values, bad pixel and column maps, patches, Huffman tables and anything else that has been loaded into RAM. When the BEP is re-powered, the default parameter blocks, tables, etc. will be copied from EEPROM into RAM, and have their respective “as-launched” values (NOTE: This affects power-consumption and the state of the focal plane temperature controller).

2.

DEA may still be running
Since the DEA and DPA have separate power supplies, the DEA interface boards and video boards will remain powered when the DPA is powered off. Whatever state the DEA is in at the time the DPA is powered down will persist, specifically, the video board power (and clocking state), and the focal plane temperature control settings (including the focal plane bake-out heater state).

3.

Associated FEPs will be powered off
Powering down DPA-A will power down BEP-A and also FEP_0, FEP_1 and FEP_2; powering down DPA-B will power down BEP-B and also FEP_3, FEP_4 and FEP_5. As noted in warning 5 of Section 3.1.2, before powering down an active BEP, it should be commanded to power down all FEPs.

3.2.2 Halting the active BEP

Description

Another method of stopping the ACIS software is to halt the active Back End Processor. This is accomplished using a Halt BEP hardware command, or by selecting the other BEP, which throws the current BEP into a reset state (note, that if the other BEP is powered, it will run).

Commands

IP&CL syntax	bcmd syntax	Command Description
1RSETIRT (v=1)	halt bep	Halt the active BEP
1BSELICL (v=1)	select bep b	Select Side-B BEP
1BSELICL (v=0)	select bep a	Select Side-A BEP

If the active BEP is not halted before the “other” BEP is selected, the former will be halted, the latter will boot up immediately and write a bepStartupMessage to telemetry. It is better practice only to issue select commands when the BEP is halted.

Engineering Telemetry

∙ Selected BEP Bi-level

1STAT4ST	= 0	Indicates BEP-A is selected
	= 1	Indicates BEP-B is selected

∙ Reset Bi-level

1STAT5ST	= 0	Selected BEP is not reset (i.e. is running)
	= 1	The currently selected BEP is held in reset

Science Telemetry

When the selected BEP is powered up and held in a reset state, it outputs a series of fill bytes, 0xb7, to the software serial digital telemetry channel.

Warning

1.

Release of reset causes boot
Refer to Section 3.1.3.2, Section 3.1.3.3, and Section 3.1.4 for descriptions of the types of boot that can occur when the BEP’s reset is released.

3.3 Changing the System Configuration

This section describes how to modify the ACIS software system configuration table, including controlling the power to the Front End Processors and the Detector Electronics Assembly Video Boards.

3.3.1 System Configuration Table

The System Configuration Table, described in Appendix C, consists of a table of various settings. These settings are broken into the following components:

• FEP and DEA Power

• DEA Interface Board Settings

• DEA Video Board Settings

The values in the table are modified using a “Change System Configuration” command packet, whose contents identify a set of items and their values to load into the table.

The instrument’s System Configuration Task polls this table once per second to see if anything has changed in the FEP/DEA Power, or DEA Interface Board settings since the last time the table was polled. If anything has changed, the task updates the corresponding power item, or item in the DEA interface board.

The DEA Video board settings, on the other hand, are only used at the start of a Science Run. At that time, they are used to configure the various Digital-to-Analog settings in the video board.

3.3.2 Controlling FEP Power

Description

The Front End Processors (FEPs) are split into two groups, FEPs 0, 1, 2 are powered by the Side-A DPA Power Supply, and FEPs 3, 4 and 5 are powered by the Side-B DPA Power Supply (refer to Table 3.2 for a description of powering the DPA Power supplies). Prior to enabling the power to a specific FEP, the appropriate supply must be on. Once the FEPs supply is on, its power must be enabled by the BEP using an entry in the Change System Configuration software command.

The FEP Power entry of the Change System Configuration command consists of a bit-map, where bit 0 (LSB) corresponds to FEP 0, bit 1 corresponds to FEP 1, etc. If the bit in the map is 0, then the corresponding FEP is powered off. If the bit is a 1, then the FEP is powered on.

In order to avoid exceeding possible power limitations (there are currently no such limitations, but things change), the System Configuration task within ACIS always first powers off those FEPs that are to be off, and then powers on the FEPs that should be running. There is a 1 second delay between each power off command. There will never be less than a 1 second delay between each power on. However, it currently takes 7 to 10 seconds to load the current FEP software into each FEP, so it can take up to 1 minute to power on all 6 FEPs. If the FEPs are already in their desired states (i.e. off or on), the System Configuration task takes no action.

The Side-A and Side-B BEPs can both enable and disable power to all 6 FEPs. In order to prevent a failure on one BEP from preventing the other being able to power on a FEP, the power enable outputs of the BEPs are logically OR’d. This can lead to confusion when selecting between BEPs. If both BEPs are powered (which they would have to be if you were using all 6 FEPs), and the previously selected BEP has power enabled to some of the FEPs, the currently selected BEP will not be able to power-off those FEPs. To avoid this condition, always issue a command to power off FEPs on the active BEP prior to selecting the other BEP.

An attempt to enable power to a FEP that does not have its corresponding power-supply on will generate a memory bus error exception on the BEP, which is trapped and handled by the BEP ONLY when the FEP is commanded on. In this situation, the System Configuration task will repeat its attempts to power on the FEP once a second. However, if a FEP is already on, and its power-supply is turned off, the next access to the FEP will cause a non-recovered bus error exception, resulting in a Fatal Error telemetry message, and watchdog reset of the BEP. Also note that, even when handled by the BEP, these bus errors will disrupt the transmission of a telemetry packet being sent to the RCTU, causing fill-pattern gaps in middle of the telemetry packets.

An un-handled memory bus exception (and resulting Fatal Error and Watchdog Reset) will also be caused if a FEP’s power is disabled in the middle of a BEP to FEP memory access. In order to avoid this, disable FEP power only when there are no science runs active, and no commanded FEP memory loads or dumps in progress.

---

Figure 3.1: FEP Power Supplies and Enables

---

Commands

∙ Change System Configuration

change n systemConfig {		# CMDOP_CHANGE_SYS_ENTRY
entries = {
itemId	= 1	# SYSSET_FEP_POWER
itemValue	= n	# FEP power bit-map, where bits 0-5
		# correspond to FEPs 0-5, respectively,
		# and bits 7-15 are unused.
}
}

∙ For example, to power-on all 6 FEPs:

change n systemConfig {		# CMDOP_CHANGE_SYS_ENTRY
entries = {
itemId	= 1	# SYSSET_FEP_POWER
itemValue	= 0x3f	# Select all 6 FEPs
}
}

∙ To power on FEP 0 only (and power off FEPs 1-5, if they were on):

change n systemConfig {		# CMDOP_CHANGE_SYS_ENTRY
entries = {
itemId	= 1	# SYSSET_FEP_POWER
itemValue	= 0x1	# Select only FEP_0
}
}

Engineering Telemetry

The only engineering telemetry items that indicate whether or not FEPs are up and running are the electric current channels. These can give an indication as to how many FEPs are on and in what state they are in, but do not give very specific information beyond that. Refer to Table E.1 in Appendix E for a table of power levels under different instrument configurations.

Science Telemetry

∙ Command Echo

commandEcho[n] = {
...
formatTag	= 7	# TTAG_CMD_ECHO
arrival	= n	# BEP timer value when command arrived
result	= 1	# Return code from command manager
changeConfigSetting = {
commandLength	= 5	# Length of command packet (half-words)
commandIdentifier	= n	# Command sequence number
commandOpcode	= 32	# CMDOP_CHANGE_SYS_ENTRY
entries[0] = {
itemId	= 1	# SYSSET_FEP_POWER
itemValue	= n	# FEP power bit-map
}
}

The result field should contain the value 1 (CMDRESULT_OK), indicating that the command was received by the BEP command manager task and dispatched to the relevant thread for processing. It does not indicate that the command was executed successfully. For that, it is necessary to wait for some telemetry indication, e.g., in the current example, for reports from software housekeeping. The housekeeping report may be split between more than one housekeeping packets.

∙ Software Housekeeping Statistics

Each previously unpowered FEP to be powered up (bits set in the itemValue, above) increments the count in software housekeeping entries SWSTAT_FEP_POWERON, SWSTAT_FEP_STARTLOAD, SWSTAT_FEP_ENDLOAD, and SWSTAT_FEP_EXECMEM, and adds 3 to the count reported in SWSTAT_FEP_WRITEMEM. Each previously powered FEP to be powered down will increment the count in SWSTAT_FEP_POWEROFF.

swHousekeeping[n] = {
...
formatTag	= 10	# TTAG_SW_HOUSE
startingBepTickCounter	= n	# Starting BEP timer value
endingBepTickCounter	= n+640	# Ending BEP timer value
statistics[0] = {
swStatisticId	= 0	# SWSTAT_VERSION
count	= 1	# Number of reports
value	= 11	# or patched or SEU or H/W error
}
statistics[1] = {
swStatisticId	= 3	# SWSTAT_TIMERCB_INVOKE
count	= 640	# Number of reports (~10/second)
value	= 0	# Most recent reported value
}
statistics[2] = {
swStatisticId	= 57	# SWSTAT_FEP_EXECMEM
count	= n	# count of FEPs being powered on
value	= n	# FEP Id of last FEP powered on
}
statistics[3] = {
swStatisticId	= 56	# SWSTAT_FEP_WRITEMEM
count	= n	# count of FEPs being powered on
value	= n	# FEP Id of last FEP powered on
}
statistics[4] = {
swStatisticId	= 76	# SWSTAT_FEPMAN_POWERON
count	= n	# count of FEPs being powered on
value	= n	# FEP Id of last FEP powered on
}
statistics[5] = {
swStatisticId	= 77	# SWSTAT_FEPMAN_POWEROFF
count	= n	# count of FEPs being powered off
value	= n	# FEP Id of last FEP powered off
}
statistics[6] = {
swStatisticId	= 78	# SWSTAT_FEPMAN_STARTLOAD
count	= n	# count of FEPs being powered on
value	= n	# FEP Id of last FEP powered on
}
statistics[7] = {
swStatisticId	= 79	# SWSTAT_FEPMAN_ENDLOAD
count	= n	# count of FEPs being powered on
value	= n	# FEP Id of last FEP powered on
}
}

If there were errors during the execution of the command, or an activity was using one of the FEPs that was being powered off, the Software Housekeeping statistics may also include entries:

SWSTAT_FEPLOCK_TIMEOUT	= 4	FEP Wait: Wait for lock timed out
SWSTAT_FEPLOCK_POWEROFF	= 5	FEP Wait: FEP has no power
SWSTAT_FEPLOCK_RESET	= 6	FEP Wait: FEP is reset
SWSTAT_FEPLOCK_NOIO	= 7	FEP Wait: FEP has no mailbox/ringbuffer
SWSTAT_FEPREPLY_TIMEOUT	= 8	FEP Reply: FEP timed out
SWSTAT_FEPREPLY_POWEROFF	= 9	FEP Reply: FEP has no power
SWSTAT_FEPREPLY_RESET	= 10	FEP Reply: FEP is reset
SWSTAT_FEPREPLY_NOIO	= 11	FEP Reply: FEP has no mailbox/ringbuffer
SWSTAT_FEPCMD_MBOXSTATE	= 54	FEP Mailbox not empty (protocol error)

If an attempt is made to enable FEP power, but its corresponding power supply is off, the following Software Housekeeping entry will be reported:

SWSTAT_INTR_FEPBUS	= 22	FEP access causes bus error exception on BEP

If power is removed while the FEP is being used during a run or memory load, a Fatal Error and Watchdog Reset may result:

∙ Fatal Error

fatalMessage[n] = {
...
formatTag	= 8	# TTAG_FATAL
bepTickCounter	= n	# BEP tick on detection of error
fatalCode	= 7	# FATAL_INTR_FEP_BUS_ERROR
fatalValue	= n	# Contents of R3000 bad virtual address register
}

Warning

1.

Power Levels
Each FEP draws a certain amount of current. The current draw is different when the FEP is held in a reset state, versus when it is fully up and running. Refer to Table E.1 in AppendixE for a table of power levels, given certain configurations.

2.

Fatal Errors
If a FEP is powered off while its memory is being accessed, it will generate an un-handled BEP memory bus exception, resulting in a Fatal Error message and BEP Watchdog reset.

3.

Power-Retries/Telemetry Disruption
If a FEP’s power-supply is off when a command is issued to enable the FEP’s power, the hardware will generate BEP memory bus exceptions, which will interfere with telemetry packet transmission (fill-bytes, 0xb7, in the middle of telemetry packets). The System Configuration task will retry the power enable once per second, which may continue to interfere with telemetry.

4.

FEP Timestamp after Power-On
The FEP science 100KHz timestamp counters are synchronized to the BEP’s 100KHz timestamp counter. They are reset to 0 whenever the BEP counter’s least significant 25 bits are 0. This occurs about once every 7 minutes. After a FEP is powered on, its counter is initially out-of-synch with the BEPs counter, and sometime within 7 minutes of being powered on, the FEP’s counter will be set to 0. From then on, the reset of the FEP counter is synchronous with its rolling-over. This can lead to confusing initial FEP timestamps if a science run starts taking data within 7 minutes of a FEP being powered on.

3.3.3 Powering the DEA Interface and Video Boards

Description

The Detector Electronics Assembly consists of two interface boards, and 10 video boards, one for each CCD. Each interface board is powered separately, the primary (board 11) from the DEA Side-A Power Supply, and the backup (board 12) from the DEA Side-B Power Supply. Only one interface board should be powered at a time. The video boards are powered in pairs via a set of latching relays on the primary interface board, and enabled via the active interface board. These relays operate from the current active power supply, and, whenever the supplies are switched, must be commanded to switch to the active supply.

Like the DPA Power Supplies, the DEA Power Supplies are commanded using hardware pulse commands, consisting of enable, on, off and disable. However, the video board relays and power enables are set from the BEP’s System Configuration Table (see Appendix C), which is modified with a “Change System Configuration” command packet. Table 3.8 shows the relationships between the CCDs, relays and video boards.

---

Table 3.8: CCD, Video Board and Power Relay Relationships

CCD	CcdId Value	Video Board	Relay Set
I0	CCD_I0 = 0	1	0
I1	CCD_I1 = 1	3	1
I2	CCD_I2 = 2	5	2
I3	CCD_I3 = 3	7	3
S0	CCD_S0 = 4	2	0
S1	CCD_S1 = 5	4	1
S2	CCD_S2 = 6	8	3
S3	CCD_S3 = 7	6	2
S4	CCD_S4 = 8	9	4
S5	CCD_S5 = 9	10	4

---

Because the ACIS software internally translates references to CCDs into DEA video board ids, all command and telemetry references identify video boards using the corresponding CCD identifier. The DEA Video Power entry of the Change System Configuration command consists of a bit-map, where bit 0 (LSB) corresponds to CCD I0, bit 1 corresponds to CCD I1, etc. If the bit in the map is 0, then the corresponding video board is powered off. If the bit is a 1, then the video board is powered on. The System Configuration Task examines its tables whenever they are altered. It powers off any video board that changes from “on” to “off”, and powers on any board that changes from “off” to “on”. To avoid stressing the power supply, the System Configuration Task ensures at least a 1 second delay between each power command. The longest power switch has been found to take between 12 seconds (all 10 boards on ⇒ off) and 16 seconds (all 10 boards off ⇒ on)..

The relays are set to point to the current power supply using the “Relay Set” entries of the Change System Configuration command. If an entry is set to a non-zero value, a command is issued to the DEA interface board to switch the corresponding relay, and the associated pair of video boards, to the currently active power supply. If an entry is set to 0, no action is taken. Since the relays are latching, they remain switched across power-cycles. The only way to “unswitch” a relay is to switch from one DEA Power Supply to the other.

Commands

To power on Side-A DEA Power Supply (and the primary DEA interface board) (NOTE: The Side-B DEA Power Supply must be off prior to issuing these commands):

IP&CL syntax	bcmd syntax	Command Description
1DEPSAEN	Enable dea a	Enable DEA Side-A Power Supply
1DEPSAON	Poweron dea a	Power On DEA Side-A Power

To power off the Side-A DEA Power Supply:

IP&CL syntax	bcmd syntax	Command Description
1DEPSAOF	poweroff dea a	Power off DEA Side-A Power Supply
1DEPSADS	disable dea a	Disable DEA Side-A Power Supply

To power on the Side-B DEA Power Supply (and the redundant DEA interface board) (NOTE: The Side-A DEA Power Supply must be off prior to issuing these commands):

IP&CL syntax	bcmd syntax	Command Description
1DEPSBEN	enable dea b	Enable DEA Side-B Power Supply
1DEPSBON	poweron dea b	Power On DEA Side-B Power

To power off the Side-B DEA Power Supply:

IP&CL syntax	bcmd syntax	Command Description
1DEPSBOF	poweroff dea b	Power off DEA Side-B Power Supply
1DEPSBDS	disable dea b	Disable DEA Side-B Power Supply

To switch all of the video relays to the currently active interface board:

change n systemConfig {		# CMDOP_CHANGE_SYS_ENTRY
entries = {
itemId	= 11	# SYSSET_CNTL_RELAY_SET_0 (CCDs I0/S0)
itemValue	= 1	# Issue switch command
}
entries = {
itemId	= 12	# SYSSET_CNTL_RELAY_SET_1 (CCDs I1/S1)
itemValue	= 1	# Issue switch command
}
entries = {
itemId	= 13	# SYSSET_CNTL_RELAY_SET_2 (CCDs I2/S3)
itemValue	= 1	# Issue switch command
}
entries = {
itemId	= 14	# SYSSET_CNTL_RELAY_SET_3 (CCDs I3/S2)
itemValue	= 1	# Issue switch command
}
entries = {
itemId	= 15	# SYSSET_CNTL_RELAY_SET_4 (CCDs S4/S5)
itemValue	= 1	# Issue switch command
}
}

Note that if itemValue is 0, then the entry has no effect on the relay setting. To power on and off the DEA Video Boards (NOTE: Either A or B side DEA Power must be on, but not both, and the relay corresponding to the desired CCDs must be switched to the active supply):

change n systemConfig {		# CMDOP_CHANGE_SYS_ENTRY
entries	= {
itemId	= 0	# SYSSET_DEA_POWER
itemValue	= n	# DEA power bit map: where bits 0-9
		# correspond to CCDs I0-S5, respectively,
		# and bits 10-15 are unused.
		# See the “Commands” section on Page 56
}
}

Engineering Telemetry

The only engineering telemetry items that indicate whether or not DEA Video boards (and by induction, their relay states) are up and running are the electric current channels. These can give an indication as to how many video boards are on and in what state they are in, but do not give very specific information beyond that. Refer to Table E.1 in Appendix E for a table of power levels under different instrument configurations.

---

Table 3.9: DEA Power Supply Verifiers

Mnemonic	Val	Status	Description
1DEPSAX	0	disabled	Verifies DEA Power Supply Side-A enabled state
	1	enabled
1DEPSA	0	not powered	Verifies DEA Power Supply Side-A powered state
	1	powered
1DEPSBX	0	disabled	Verifies DEA Power Supply Side-B enabled state
	1	enabled
1DEPSA	0	not powered	Verifies DEA Power Supply Side-B powered state
	1	powered

---

Science Telemetry

∙ Command Echo from Relay Command

commandEcho[n] = {
...
formatTag	= 7	# TTAG_CMD_ECHO
arrival	= n	# BEP timer value when command arrived
result	= 1	# Return code from command manager
changeConfigSetting	= {
...
entries[0] = {
itemId	= 11	# SYSSET_CNTL_RELAY_SET_0
itemValue	= 1	# Issue switch command
}
entries[1] = {
itemId	= 12	# SYSSET_CNTL_RELAY_SET_1
itemValue	= 1	# Issue switch command
}
entries[2] = {
itemId	= 13	# SYSSET_CNTL_RELAY_SET_2
itemValue	= 1	# Issue switch command
}
entries[3] = {
itemId	= 14	# SYSSET_CNTL_RELAY_SET_3
itemValue	= 1	# Issue switch command
}
entries[4] = {
itemId	= 15	# SYSSET_CNTL_RELAY_SET_4
itemValue	= 1	# Issue switch command
}
}
}

Note that the 5 SYSSET_CNTL_RELAY_SET indicators only show the desired relay positions, not whether the relays actually switched. The same is true of these fields in the system configuration table (see Table 3.10).

∙ Command Echo from DEA Video Board Power Enable

commandEcho[n] = {
...
formatTag	= 7	# TTAG_CMD_ECHO
arrival	= n	# BEP timer value when command arrived
result	= 1	# Return code from command manager
changeConfigSetting	= {
...
entries[0] = {
itemId	= 0	# SYSSET_DEA_POWER
itemValue	= 1	# DEA Video Board power bit-map
}
}

∙ Software Housekeeping Statistics

swHousekeeping[n] = {
...
formatTag	= 10	# TTAG_SW_HOUSE
startingBepTickCounter	= n	# Starting BEP timer value
endingBepTickCounter	= n+640	# Ending BEP timer value
statistics[0] = {
swStatisticId	= 0	# SWSTAT_VERSION
count	= 1	# Number of reports
value	= 11	# =11 or patch # or SEU or H/W error
}
statistics[1] = {
swStatisticId	= 3	# SWSTAT_TIMERCB_INVOKE
count	= 640	# Number of reports
value	= 0	# or SEU or H/W error
}
statistics[2] = {
swStatisticId	= 81	# SWSTAT_DEACCD_POWEROFF
count	= n	# Number of Video boards being powered off
value	= n	# CCD Id associated with last Video turned off
}
statistics[3] = {
swStatisticId	= 80	# SWSTAT_DEACCD_POWERON
count	= n	# count of Video boards being powered on
value	= n	# CCD Id associated with last Video turned on
}
}

If an error is encountered while commanding the DEA, either to switch the relays, or control power to the video boards, the following housekeeping entry will be supplied:

SWSTAT_DEABOARD_ERROR	= 53	Error issuing command to DEA interface

where the 16 least significant bits of reported value field contain an internal software error code, and the most significant 16 bits of the value field contain the video board slot index (as opposed to the CCD Id), or “11” if the command was directed to the interface board.

If DEA Housekeeping is running (see Section 3.4.6) and is querying the state of the relays, it will be indicated as follows:

deaHousekeepingData[n] {
...
formatTag	= 11	# TTAG_DEA_HOUSE
deaBlockId	= n	# Id of parameter block used for the DEA Run
commandId	= n	# Id of the command that started the DEA Run
bepTickCounter	= n	# BEP Interrupt Count (10Hz tick) at start of
		# DEA housekeeping acquisition
entries[0] = {
ccdId	= 10	# =10 CCD_DESELECT indicating the interface board
queryId	= 0	# DEAHOUSE_CNTL_RELAY (state of relays)
value	= n†	# State of the relays
}
}

^† Bit 0 of the DEAHOUSE_CNTL_RELAY channel corresponds to relay set 0 (see Table 3.8), bit 1 to relay set 1, etc. If a bit is 0, the relay set is not switched to the active supply. If a bit is 1, then the relay set is switched, and the corresponding pair of video boards can be powered. For example, when DEA-A is powered, a value of 0x1f indicates that all boards are able to receive power from DEA-A; a value of 0x0 indicates that all boards could receive power from DEA-B, but not from DEA-A.

While the video boards are not powered (or if errors occur), any active DEA Housekeeping queries to the video boards will result in a “value” field of 0xffff.

If errors occur in queries to the interface board, the “value” field will contain 0xffff (for example, if there’s no DEA power supply turned on).

Warning