Preface: MOXE Flight Software Overview T. Nolan Rev 1.3 - 7/2/93 revised PTB 9/4/96 Contents: 1. Hardware Description 2. Power Up and Reset 2.1 Turtle Mode 3. 8086 Interrupts 3.1 1553 Bus Command Interrupts 3.2 One Second Timer Interrupt 3.3 MOXE Talk Interrupts 3.4 High Voltage Turn-Off Interrupts 3.5 SDX Transmit Done Interrupt 3.6 Non-Maskable Interrupt 4. 1750 Interrupts 4.1 Detector Event Interrupts 4.2 8086 Software Generated Interrupt 4.3 One Second Timer Interrupt 5. MOXE Data Collection and Transmission 5.1 Data Collection 5.2 Data Transmission 6. MOXE Commanding 6.1 Receive Control Code Word 6.2 Receive Time Code 6.3 Transmit Science Data 6.4 Retransmit Science Data 6.5 Transmit Housekeeping Data 6.6 Retransmit Status Word 6.7 Begin Ground Contact 6.8 Start Observation 6.9 Finish Observation 6.10 Emergency Cut-Off 6.11 Enter Radiation Belt 6.12 Battery Discharge 7. Troubleshooting 8. Building the Flight Software from Sources 1. Hardware Description The MOXE flight software runs on the MOXE digital microprocessor system. This system consists of three major subsystems: the 8086 CPU, the 1750 CPU, and the ILMM mass memory. The 8086 CPU is the system controller. When power is applied, the 8086 begins executing its ROM software, which contains the routines to transfer the program load to the 1750 CPU and start the 1750 running; to reset the ILMM to its initial empty state; to monitor the instrument status; and to respond to 1553 commands from the spacecraft BIUS. The 1750 CPU is the detector event processing engine. It responds to detected X-ray events from the six detectors by reading the events, compressing the position and time information, and placing the compressed events into the ILMM buffers. As each buffer is filled, the 1750 sets the ILMM flag register to transfer control of the buffer to the ILMM. The 1750 also collects periodic instrument status and transfers this housekeeping information to the ILMM, where it is interleaved with the event data. The ILMM is a 125M-byte memory module (904K in the engineering model). It operates as a FIFO storage system, with error detection and correction code running periodically to ensure data integrity. The ILMM accepts science and housekeeping data in 2048-byte blocks from the 1750 CPU while the instrument is observing. During ground contact, the ILMM transfers these data blocks, under control of the 8086 CPU, in the order in which they were received, for transmission to the spacecraft over the 1553 bus. 2. Power Up and Reset When power is applied or a master reset occurs, the 8086 CPU begins executing its reset code. For the first eight seconds of operation, the 8086 runs in ÒturtleÓ mode. During these eight seconds, the 8086 disables all of its functions except for the ability to receive certain commands from the 1553 bus. The theory of operation is that portions of the digital microprocessor hardware may fail during flight, in a way that would cause a synchronous reset if any access were attempted. The eight seconds after powerup permit ground controllers to command MOXE into one of several modes in which it does not attempt to access various portions of its hardware. In these modes MOXE capabilities are significantly impaired, but it remains alive to permit further diagnosis and corrective action. After the eight seconds are up, the 8086 initializes its hardware and software as instructed. Before the 1750 can run, the 8086 must download its code from ROM to 1750 instruction RAM. All of the power up and master reset functions of the 8086 are summarized in the following list. Reset and hold 1750 Transfer 1750 program from ROM to instruction RAM Transfer ROM copy of EEPROM map to operand RAM Transfer initialized 8086 C data from ROM to RAM Zero uninitialized C data segment Transfer to C turtle_main() program Load ramswitch from EEPROM swswitch (or from ROM if EEPROM copies differ) Wait for 8 seconds Transfer to C main() program Initialize command queue Install interrupt vectors, initialize interrupt controllers Read all temperature monitors through ADC Load EEPROM map to operand RAM: For each location, find two map values that agree If all maps differ, set error flag and retain ROM value Read current HV settings, turn on HV according to bit mask Write initial detector threshold settings Turn data throttles off (accept all events) Write 1750 time, data cycle counter, swswitch Start 1750 program running 2.1 Turtle Mode Turtle mode allows the RAM copy of swswitch to be modified by command during the eight second delay. The swswitch options are to disable ILMM access; to disable EEPROM writes and use the ROM copy of the operating parameters; or to disable the watchdog timer reset. In normal operation, all three (the ILMM, the EEPROM, and the watchdog timer) are enabled. During the turtle mode delay, other commands are not accepted. The following table describes the commands and responses during the first eight seconds after power is applied. Note that the normal action and response to each command outside of turtle mode is described in Section 6 below. Command Action 2222 C000 xx Change ramswitch to xx 2222 C001 xx Change turtle delay time from 8 seconds to xx All other 2222 commands Status=2000h, no action Xmit Vector Word Status=2000h, vector word=0 Xmit Science Data Status=2400h (error), no data Xmit Housekeeping Status=2000h, 13 words sent: 0800h, data cycle, 9*0, command echo All other commands No status, no action After the turtle mode time elapses, the 8086 begins responding normally to 1553 bus commands. The 1750 delays an additional amount of time before beginning to process incoming X-ray events in order to give the ILMM sufficient time to complete its reset operations. The additional ILMM delay time is a commandable parameter in EEPROM. Any changes made during turtle mode are only temporary, since only the RAM copy of the software switches may be modified. After changes have been made and instrument operation successfully corrected, the EEPROM copies of the software switches should be modified during normal operation so that the configuration will be preserved across resets. For more information on troubleshooting, see Section 7 below. 3. 8086 Interrupts The 8086 CPU runs a background program which is interrupted by various external events. The 8086 handles these events in high priority interrupt service routines, often queueing messages to be handled at a lower priority by the background program. The following table lists the interrupts in priority order, highest to lowest. Interrupt Description 0 1553 Bus A Command 1 1553 Bus B Command 2 One-second timer 3 ÒMOXE TalkÓ Bus A 4 ÒMOXE TalkÓ Bus B 5 Cascade to 2nd Interrupt Controller 6 Not used 7 Not used 8 High voltage turn-off, Detector 1 9 High voltage turn-off, Detector 2 10 High voltage turn-off, Detector 3 11 High voltage turn-off, Detector 4 12 High voltage turn-off, Detector 5 13 High voltage turn-off, Detector 6 14 SDX Transmit Done 3.1 1553 Bus Command Interrupts These two interrupt service routines are activated whenever a command is received by MOXE over the 1553 spacecraft bus A or B, respectively. The 1553 receiver hardware has circuitry to filter out all but MOXE and broadcast commands and their associated data words, so the software does not have to perform this filtering function. The receiver hardware collects incoming command and data words from the 1553 bus into a hardware FIFO. When the FIFO is non-empty, the corresponding bus A or bus B interrupt signal is asserted. The ISR reads the command word, analyzes the command to find the number of associated data words (if any), and then reads the data words, waiting in a loop if necessary while the data words arrive. Too few data words can therefore hang up the flight software, but receiving a new command word will resynchronize it. Because of the stringent timing requirements, the interrupt service routine performs only enough analysis of the command to form the correct status response. The ISR collects the command word and the data words into a command block and transmits the status response, if one is required by the command, over the 1553 bus after preliminary command checking is complete. After transmitting the response the ISR places the completed command block in a queue for further analysis in the background routine. The background routine pulls blocks off the queue in the order in which they were received and performs further command processing. A list of the 1553 bus commands to which MOXE responds may be found in Section 6 below. 3.2 One Second Timer Interrupt The 8086 is interrupted once per second by hardware timer logic. The purpose of the interrupt is to schedule timed operations. Following is a list of all of the functions that the 8086 performs on one-second and four-second intervals. Most of these tasks are actually performed in the background after a flag is set by the one-second interrupt routine. Every second: Reset watchdog timer Count down ILMM reset time, turn on ILMM when done Set flag to process next internal macro sequence command Reset 1750 if its internal counter is out of sync Monitor detector LL and Anti counts per second, turn off HV if too high Count time HV is off (for any reason), turn on HV when time elapsed Step HV up or down if not at target voltage Every 4 seconds: Check data throttle periods, reset if finished; Check events rate for data throttles 3.3 MOXE Talk Interrupts These interrupts are provided for hardware diagnostics. They are push-button interrupts that cause MOXE to transmit 1024 words to the 1553 bus. The first word is status (2100h), the next 1023 words are an increasing data pattern. 3.4 High Voltage Turn-Off Interrupts There are six interrupts, one associated with each MOXE detector, that are asserted whenever the corresponding detector anode current is too high. The detector high voltage is turned off in hardware, and the software is notified via one of these interrupts. In the interrupt service routine, the program sets the high voltage target value to zero, then posts a specified period of time to wait before turing the high voltage back on. In the background routine the program waits for the requested time interval as described in Section 3.2 above, then turns on the high voltage and ramps up to the commanded nominal high voltage setting. The time delay is a commandable parameter in EEPROM. 3.5 SDX Transmit Done Interrupt The serial data transmitter (SDX) chip and its associated serial data receivers (SDR) are semi- custom gate arrays on the 8086 CPU board. They allow command bits to be set and held in hardware, and command status to be read back. The 8086 board provides an interrupt that can notify the processor when a serial command is complete. This interrupt may be used to implement a queueing scheme. In the current implementation, this interrupt is not used. Rather, the 8086 always waits in a busy loop after sending an SDX command until the transmission is done. In case the SDX is hung up, the busy loop will time out after a certain interval; this causes one of 6 error counters to increment depending on the detector to which the command was addressed. 3.6 Non-Maskable Interrupt The 8086 non-maskable interrupt (NMI) is associated with the watchdog timer circuitry. The 8086 code resets the watchdog timer as part of its normal one-second operations. If two seconds elapse without such a reset, the watchdog timer asserts the NMI interrupt. Within the NMI interrupt service routine, two actions are possible. Under normal operation, the watchdog timer causes a full microprocessor reset by jumping to the 8086 reset vector. However, if the software switch (swswitch) is set to disable the watchdog timer, then the NMI interrupt is dismissed and the CPU resumes the operation from which it was interrupted. The software switch is a commandable parameter in EEPROM, that may also be temporarily modified during turtle mode. For more information, see Sections 2.1 and 7. 4. 1750 Interrupts The 1750 runs as a background program with interrupts. The 1750 uses a software interrupt priority rotation to give equal priority to each of the detector event interrupts. The following table lists the 1750 interrupts. They are given in nominal priority order, highest to lowest. Interrupt Description INT0 One second timer INT1 Detector 1 event data ready INT2 Detector 2 event data ready INT3 Detector 3 event data ready IOL0 Detector 4 event data ready INT4 Detector 5 event data ready IOL1 Detector 6 event data ready INT5 8086 Software-generated interrupt 4.1 Detector Event Interrupts There are six interrupts, one associated with each detector. When a detector finishes an event conversion, it raises its interrupt signal. The 1750 software reads in the event information, resetting the detector circuitry and allowing the next conversion. The main action performed by the 1750 is to read the event, compress it to 3 bytes, and write it to the ILMM. However, there are a number of ancillary event-counting functions performed as well. The following list summarizes all of the 1750 processing for each event. Read event from hardware registers Check if detector is enabled, exit if not Increment llevent counter for this detector If risetime bit is set: Increment rtevent counter for this detector Check if risetime events are enabled for t/m, reject if not If anti bit is set: Increment antievent counter for this detector Check if anti events are enabled for t/m, reject if not Compress pha, increment aboveevent and belowevent counters as appropriate Increment valid event counter if not risetime and not anti event If event is in a hot spot for this detector: Count into accum histograms Check if hot spot events are enabled for t/m, reject event if not If event is in Fe55 boxes: Compress and accumulate into Fe55 histogram Check if Fe55 events are enabled for t/m, reject event if not Add event into X and Y sun histograms If event is in current sun box: Increment sunrej counter for this detector Check if sun events are enabled for t/m, reject event if not Add event into throttle counters Perform random number generation and throttle test, may cause event to be rejected and counted Increment tmevent counter for this detector, event will be written to ILMM Compute relative time from previous event, generate time overflow event if necessary Write event into ILMM buffer 4.2 8086 Software Generated Interrupt The software generated signal allows the 8086 to interrupt the 1750. It is not used in the present implementation. 4.3 One Second Timer Interrupt The 1750 is interrupted once per second by the same hardware timing logic that generates the 8086 one second timer. The purpose of the interrupt is to provide event timing and process synchronization. The 8086 will reset the 1750 if the 1750Õs one-second counter (datacycle1750) does not agree with the 8086Õs one-second counter (datacycle8086). The one-second time base also drives the accumulation and transmission of housekeeping data. The following list describes the processing at the one-second interrupt. Increment datacycle1750 Read and clear hardware counters, accumulating into software buffers If one-second housekeeping is enabled, create next 1-sec block and write to ILMM Store present HV value for special selected detector Compute elapsed time of current ILMM event buffer, fill and write to ILMM if max time exceeded On 4-second boundary: Fill in next 4-second HK block On 16-second boundary: Fill in next 16-second HK block Compute new sun position from X and Y sun histograms If detector high voltage has reached target setting, enable detector On 64-second boundary: Fill in next 64-second HK block Write 64-second block (including 4-sec and 16-sec blocks) to ILMM On 512-second boundary: Fill in next 512-second HK block 5. MOXE Data Collection and Transmission MOXE is designed to observe and accumulate data autonomously for long periods of time, and then to transmit the accumulated observations during brief periods of ground contact. The following sections describe these phases of operation in more detail. 5.1 Data Collection In the normal operating mode, the MOXE instrument collects event data from the six detectors into 1024-word blocks and places the blocks in the ILMM for storage until they can be transmitted to the ground during a ground contact period. Interleaved among the event data blocks are housekeeping data blocks, which contain instrument status and program operation information. The housekeeping blocks are placed in the ILMM every 64 seconds, with an 8- minute commutation cycle. Each event occupies 3 bytes, containing flag bits, compressed PHA and time information, and X and Y energies. The 1K-word ILMM data buffers each hold 600 events. At the nominal event rate of 300 events/second, the ILMM can store about 30 hours of data (15 minutes in the engineering model). To keep the ILMM from filling up too rapidly, a system of data throttles is implemented in the flight software. The data throttle characteristics are commandable. When the event rate exceeds a throttle threshold, the throttle engages, and begins discarding some fraction of the received events. The discarded events are counted and recorded in the 64-second housekeeping. The flight software also computes the position of the sun, and rejects events that it finds within the sun box. The sun position is based upon a characteristic increase in counting rates within a small area of one detector. Finally, the flight software contains provisions to reject events within detector Òhot spots.Ó The coordinates of the hot spots may be determined by analysis of the telemetry data and uploaded by command. As an additional diagnostic, the instrument can be commanded to collect special one-second housekeeping blocks, which track the instrument status on a much finer time scale than the normal 64-second housekeeping. The special one-second housekeeping blocks, when enabled, are also placed in the ILMM along with the normal housekeeping and event data. The instrument can also be commanded to write its EEPROM contents into special blocks for storage in the ILMM and later interpretation. The EEPROM contains the commanded state of the instrument and may be referred to as necessary to understand the operation of the instrument in detail. It should be stressed that despite the presence of instrument housekeeping, all of the ILMM data comes under the name of Òscience dataÓ and is transmitted as part of the instrument scientific data stream. All scientific data blocks have a 7-word transmission header, a 4-word block header and a 900-word data area. The blocks are distinguishable by their block type, found within the block header. The details of the scientific data formats are found in a separate document. 5.2 Data Transmission Data stored in the ILMM is only retrievable during a ground contact. At the start of a ground contact, MOXE informs the spacecraft of the number of 1024-word blocks contained within the ILMM. Under spacecraft control, MOXE retrieves the blocks from the ILMM in the order in which they were placed there, and transmits the data over the 1553 bus. During this transmission time, MOXE can still collect event and housekeeping data, but at a reduced rate. When the transmission is over, MOXE returns to its normal data collection mode and awaits another ground contact. To initiate a ground contact requires a specific command sequence. The first command is ÒBegin Ground Contact.Ó On receipt of this command, MOXE turns on the ILMM transmit bit, which will remain on for the duration of the ground contact. The state of the ILMM transmit bit determines how MOXE responds to certain of the 1553 bus commands. The next command is ÒTransmit Vector Word.Ó This command informs the ground station how many science data blocks are currently contained within the ILMM, and instructs MOXE to prepare to transmit the data. Following this, a number of ÒTransmit Science DataÓ commands are expected. Each command causes MOXE to retrieve the next oldest data block in sequence from the ILMM and transmit it to the ground. When the last block is requested, MOXE turns off the ILMM transmit bit and resumes normal data collection. In the event that the ground contact is cut short, the transmit bit will be turned off automatically after a certain time elapses, and may also be turned off by explicit command. More information on the individual commands in this sequence may be found in Section 6. The following command sequences illustrates how the ground contact commands work. Command or Action Description of MOXE response Power Up Sets ILMM output pointer to null Begin Ground Contact Turns on transmit bit Transmit Vector Word Returns number of blocks, sets ILMM output pointer to 1st block Transmit Science Data Reads and transmits next ILMM block Ò Repeated for the number of blocks returned in vector word Transmit Science Data Error status returned (last block already sent, transmit bit is off) Power Up Resets ILMM output pointer to null Transmit Vector Word Returns number of blocks but does not change ILMM output pointer Transmit Science Data Returns error status (transmit bit is off) Begin Ground Contact Turns transmit bit on Transmit Vector Word Returns number of blocks, sets ILMM output pointer to 1st block Transmit Science Data Reads and transmits next ILMM block Transmit Vector Word Updates and returns new number of blocks but does not change output pointer Transmit Science Data Reads and transmits next ILMM block Ò Repeated for the number of blocks returned in last vector word Transmit Science Data Error status returned (last block already sent, transmit bit is off) 6. MOXE Commanding The SRG spacecraft controls MOXE by issuing commands to it over the spacecraft 1553 bus. The format for all command and data traffic on the 1553 bus is defined in the SRG Bus Standard. MOXE responds to commands sent to the MOXE instrument address, and to certain broadcast commands intended for all instruments. The following table specifies the commands to which MOXE responds. In the table, bits marked ÔX' are don't-care. The SRG Bus Standard specifies bits in these positions, but MOXE does not interpret them, relying instead on information in the other fields. MOXE can handle many of the Òmode codeÓ commands (subaddress field all 1Õs) either as broadcast commands or as specific MOXE commands. The only difference in the handling is that MOXE transmits a status word in response to MOXE commands, but does not transmit status in response to broadcast commands. Broadcast/ MOXE T/R Sub- address Count/ Code Description M R XXXXX 2 Receive Control Code Word B R XXXXX 2 Receive Time Code M T XXXX0 1024 Transmit Science Data M T XXXX1 1024 Retransmit Science Data M T XXXXX 16 Transmit Housekeeping Data M T 11111 2 Retransmit Status Word B/M T 11111 9 Begin Ground Contact B/M T 11111 10 Start Observation B/M T 11111 11 Finish Observation B/M T 11111 12 Emergency Cut-off B/M T 11111 13 Enter Radiation Belt B/M T 11111 15 Battery Discharge M T 11111 16 Transmit Vector Word MOXE normally sends a status word immediately upon receiving and decoding a valid MOXE instrument command. If the command requires MOXE to respond with one or more data words, it sends those data words immediately following the status word. MOXE does not send a status word in response to a valid broadcast command, nor does MOXE send a status word if an error prevents it from decoding the command correctly. Instead, in either of these cases, MOXE forms the status word resulting from the command and retains it. This status word can then be requested by a ÒRetransmit StatusÓ command. The next table describes the status words that MOXE sends upon receiving and decoding a valid MOXE instrument command. Status Hex Description Good 2000h Good status from MOXE instrument Error 2400h Error in command or previous command Service Request 2100h MOXE has scientific data to transmit (sent on all but last science data block) Busy 2008h MOXE cannot respond to command at present Various kinds of transmission errors may prevent the instrument from understanding a command as a valid MOXE or broadcast command. Whenever one of these errors occurs, no status word is returned to the spacecraft, but the status may later be requested. Instead, MOXE counts the error into one of several counters. The number of times each of the errors occurs is then transmitted in the housekeeping data. The possible errors that MOXE may encounter are as follows (the error code refers to the counter number incremented in the 64-second housekeeping data): Error Code Cause 1 Command word received when data word expected 2 Error receiving command word 3 Data word received when command word expected 4 Error receiving one or more data words The next sections describe in detail the SRG bus commands, the actions taken, and the status returned. 6.1 Receive Control Code Word The ÒReceive Control Code WordÓ command, always with two associated data words, is used as the primary means of MOXE instrument configuration. MOXE has a number of parameters and variables that control instrument settings, data types, diagnostics, and other aspects of operation. The full set of control commands is documented elsewhere. ÒReceive Control Code WordÓ commands are also referred to as Ò2222Ó commands, because that is the bit mapping of the command word to MOXE in hex. Most of the MOXE control code commands are used to change parameters that are kept in EEPROM. Once changed, the new parameter settings remain in EEPROM across system resets. For safety reasons, there are four copies of the EEPROM parameters. When a command modifies the first bank, the software automatically updates the other three banks and the operating copy in 1750 operand RAM. Certain EEPROM locations also require additional processing; these are listed below. All other EEPROM commands take effect by only by modifying variables used by the 1750 in its processing algorithm. thottlenab (detector throttle enable bit mask): Set all four throttle enable bits from bits 3-0 Reset throttle times detset (detector threshold setting): Enable/disable sun reject according to bit 7 Write bits 5-0 to detector threshold I/O port hvset (high voltage setting): Turn on/off high voltage according to bit 7 Set detector hv target according to bits 6-0 Issue new hv on/off status to detector analog board 6.2 Receive Time Code The ÒReceive Time CodeÓ command causes MOXE to acquire the two-word time code from the spacecraft. MOXE only accepts this command as a broadcast command. MOXE does not interpret the spacecraft time, but places it in the header of all stored science and housekeeping data. 6.3 Transmit Science Data The ÒTransmit Science DataÓ command causes MOXE to send status plus 1024 words of science data. It must be issued as part of a sequence, or an error will result. The first command in the sequence must be ÒBegin Ground Contact.Ó This causes MOXE to place the ILMM in transmit mode, and read the number of data blocks contained therein. The next command must be ÒTransmit Vector Word.Ó This causes MOXE to transmit the number of data blocks in the ILMM and ready the first block for transmission. These two commands may be followed by any number of ÒTransmit Science DataÓ commands. MOXE will take the ILMM out of transmit mode when any of the following occurs: the last block is requested from the ILMM; a certain time elapses after the ÒBegin Ground ContactÓ; or a specific ÒReceive Control Code WordÓ command is sent from the ground. In response to each ÒTransmit Science DataÓ command, MOXE may return one of four different status words: error, busy, service request, or good status. Error is returned if MOXE receives the ÒTransmit Science DataÓ out of sequence, or after all science data blocks are transmitted. Busy is returned if the ILMM has not presented the next data block to be transmitted. Service request is returned on all data blocks except the last, indicating that MOXE has more science data to send. Good status is returned on the last science data block of the sequence. 6.4 Retransmit Science Data MOXE keeps a copy of the last science data block that it sent in response to ÒTransmit Science Data.Ó This block may be requested again, as many times as necessary, by issuing ÒRetransmit Science Data.Ó There is no way to recover any other data taken out of the ILMM except this most recent block. 6.5 Transmit Housekeeping Data The ÒTransmit Housekeeping DataÓ command causes MOXE to respond with status and 15 words of housekeeping information, which is also referred to as Òslow telemetry.Ó There are 16 different blocks that MOXE can transmit in response to this command. The blocks are self- identifying. Normally, MOXE cycles through an eight-block sequence, transmitting the next block in the sequence on each successive ÒTransmit Housekeeping DataÓ request. The information in these housekeeping blocks is mostly duplicated in the 64-second housekeeping blocks stored in the ILMM. The advantage of the slow telemetry is that it affords an instantaneous diagnostic tool, and can be repeated as rapidly as required. However, most of the information in these housekeeping blocks is only updated within the instrument on a one-second time basis. The format for the 15-word housekeeping data blocks is described elsewhere. 6.6 Retransmit Status Word The ÒRetransmit Status WordÓ command causes MOXE to report the status from the previous command. It may be used when MOXE does not respond with a status word, to find out whether there was an error. 6.7 Begin Ground Contact ÒBegin Ground ContactÓ informs MOXE that a science data transmission is to follow. It is a required command. MOXE must receive this command to ready the ILMM before the science data may be requested. The vector word may be requested at any time, with or without a ÒBegin Ground Contact.Ó For more information on the ground contact command sequence, see Section 5.2. This command may be sent as either a broadcast command or a MOXE command. MOXE does not observe the spacecraft convention that a ÒBegin Ground ContactÓ issued to the MOXE address restarts the ground contact, since the ILMM is not capable of restarting a ground contact. 6.8 Start Observation The ÒStart ObservationÓ command causes the high voltage on the six detectors to begin to ramp up to their target high voltage settings. 6.9 Finish Observation The ÒFinish ObservationÓ command turns off the ILMM transmit bit in the present implementation. 6.10 Emergency Cut-Off When MOXE receives an ÒEmergency Cut-OffÓ command, either as a broadcast or a MOXE command, it turns off high voltage on all six detectors, by ramping the high voltages down to zero from their current settings. 6.11 Enter Radiation Belt When MOXE receives an ÒEnter Radiation BeltÓ command, either as a broadcast or a MOXE command, it ramps down the high voltage on all six detectors, turns the detector enable bits off, and sets a clock timer to re-enable the detectors and ramp up the high voltage after a certain period of time has elapsed. The time period is a commandable parameter in EEPROM. 6.12 Battery Discharge MOXE does not perform any special processing in response to the ÒBattery DischargeÓ command. 6.13 Transmit Vector Word The ÒTransmit Vector WordÓ command is a part of the science data transmission (ground contact) sequence. It may be sent at any time to request the number of 1K-word blocks currently stored in the ILMM. It must be sent after ÒBegin Ground ContactÓ before any science data can be requested. 7. Troubleshooting The following table illustrates the failure modes of various components of the microprocessor system, and the operator actions for recovery. In some cases the system is designed to recover autonomously. Component Failure Action 8086 Reset Failure Power down, then power up. Frequent crashes SWSWITCH command controls action upon reset. May be used to disable EEPROM, watchdog timer, ILMM. Turtle mode allows temporary reconfiguration during 8 seconds after reset. 1750 Crash ILMM data is unaffected. ILMM Failure Any word may be placed in slow HK for telemetry. 1750 contains a single buffer backup. Hangup Use CC00 command to reset ILMM from 8086. 1Hz Timer No 1-sec interrupt Turtle mode times out in software, MOXE produces science data (no time tags) but no 64-sec housekeeping EEPROM Bit failure The voting process involving 4 copies of operating parameters guards against single-point failures of EEPROM. Complete failure The ROM contains a backup copy of the EEPROM data. RAM copied may be modified by command, but values thus modified are lost on reset. Detectors Constant interrupts Use DETENBUFF command to disable individual detector interrupts. Electrometer stuck Use TBD command to disable electrometer. Hot Spots Use commands to reject data inside hot spots. UL bit stuck Use DETSET, TMGATE commands to control. Risetime bit stuck Use DETSET, TMGATE commands to control. Anti bit stuck Use DETSET, TMGATE commands to control. High event rate Use throttles to control data rate. Use LLRATELIMIT, ANTILIMIT HVTIMEOFF commands to turn of HV if counting rate thresholds are exceeded. HV Fluctuating arcs Study high voltage at 1-sec intervals through SPECIALDET command. Electrometer system shuts off high voltage automatically, use HVTIMEOFF command to control time before ramping up. 8. Building the Flight Software from Sources The MOXE flight software source code resides in a number of files, which are assembled or compiled, then linked and packed into a binary ROM image. Several locally-written utility programs are also required during the image creation. These utility programs were written in C for this and other projects, and source code for these programs exists. Commercial compilers used are Microsoft C (version 6.0), Microsoft Assembler; UTMC RISC Assembler and RISC Linker; XLINK86, XLOC86, and PROM86 (relocating linker package from Systems & Software, Inc). The following table describes all of the files that are used in the course of building the flight software from sources. File Name Type Description moxrom.asm 8086 Asm Reset entry point moxedev.asm 8086 Asm Device initialization moxeisr.asm 8086 Asm Interrupt service routines moxe_main.c C MOXE main 8086 program & subroutines queue.c C Enqueue-dequeue subroutines list.c C List manipulation subroutines list.h C List structure definitions moxe.h C MOXE data types and hardware locations demo.ras 1750 Rasm 1750 source code (RISC assembly language) mox.m Make Make file for building MOXE ROM image from sources symbol2.exe Utility Make a symbol table from 1750 hex file var1750.exe Utility make Òvar.hÓ file from symbol table makebin.exe Utility Make a binary image from a 1750 hex file concat.exe Utility Concatenate separate binary files binhex.exe Utility Convert binary image to Intel hex file MOXE Flight Software -