The Galileo Energetic Particles Detector

Galileo EPD Handbook

Chapter 1. Instrument Summary

Software Changes

Source: Stephen Jaskulek, October 2, 1987

Flight Operating System Software Changes

One of the more important aspects to changing the flight instrument is the need to modify the instrument's flight operating system code that resides on the data system board. The software needs to be changed to allow us to command, operate, and monitor the functioning of the new hardware, and properly format the new science data.

With the exception of a small, non-crucial piece of code, all of the instrument's operating system presently resides in ROM. This means that the software is unlikely to "crash" due to soft upset errors or erroneous "write" operations.  We would prefer to use ROMs to implement the new software, but the amount of time and money appear to be prohibitive. It is therefore our intention to use RAM-resident software code to effect the desired operation system changes.

We have been able to design the proposed software and hardware changes such that the LEMMS and CMS prime side could still operate properly if we were unable to run our new software.  In this way, we can localize the risk from this redesign effort to only the new sensor and high voltage supply.

COMMANDS

The best way to process these new commands is a patch to the RTI 9 software code, where the command decoding takes place.  It is my present plan to utilize two unused command codes (FC and FD) as new HV control commands.  In order to do this, the operating system software code between the start of the RTI 9 code and the start of the command processor will have to be duplicated in RAM before any new software can be added.  In this way, the RTI 9 execution will jump to the new RAM section, execute the old processing software, then enter the new command decoder software.  The new software will check for the new command codes, execute the required operations if they are present, and then jump back to the start of the old command processor software.

Initial estimates for this part of the software updates would be about 80 bytes to reach the command decoder (copied straight from ROM code [085E to 08AE], 60 bytes to check if one of the new commands is present and increment the general command counter, 15 bytes each for commands "FC" and "F3," and perhaps 45 bytes for command "FD." An additional 20 bytes would be needed to report the value of the HV reference bytes via a spare subcommutated housekeeping byte.  This adds up to a total requirement of perhaps 235 bytes to process the three new commands.

If sufficient RAM is available, this might also be a good place to implement the VITO OVERRIDE function via a separate command rather than the present RAM-patch method (this is definitely icing on the cake, however).  This would require perhaps 20 bytes more.

It should be noted that this is the desired command set; it can be simplified if necessary.

HOUSEKEEPING

These commands can be verified in the EPD telemetry via the analog subcommutated housekeeping.  Two spare subcom locations will be used; location 86 (JPL S.I.) will contain the HV limit byte, and location 87 (JPL S.I.) will contain the HV analog monitor byte.

It should be noted that the amount of current being drawn by the new HV power supply will not be included in the EPD current monitor value.  This means that there is unfortunately no good way to determine how much power the converter is using.

RATE CHANNELS

The accumulator services routines were designed to be altered via RAM patches. It is therefore somewhat efficient to implement the desired changes.  Implementing the new C format will require that a new table be generated in RAM; no J or J' formats would be necessary.  Because the L format is unchanged, the existing table will be used.  If the C format could not be generated during the mission (for some reason), the existing J format could be used unchanged, with only a slight effect on the CMS rate channels (the two new multiplexed channels TH1 and TACs would not be accumulated).

An initial estimate for this change is about 70 bytes for the C accumulator service routine (7 bytes to load the new table address and 63 bytes for the table itself). Since the L table can be used as is, this adds up to a total requirement of perhaps 70 bytes to process the modified accumulator service tables.

TOTAL RAM REQUIREMENTS

The present EPD data system design has approximately 768 bytes of continuous RAM space available for RAM patches (plus an undefined area now used for the stack). Of this, the first 36 bytes are used for the patch hooks themselves (1800 - 1824 Hex), thus leaving 732 bytes for new operating software.  We are also already implementing a patch in RTI 9 which enables us to determine via subcom data whether the alarm monitor is enabled and whether the LEMMS PHA is enabled.  This patch, which could simply be added to the new RTI 9 command processing patch, requires about 35 bytes of RAM.

In the paragraphs above, a preliminary estimate shows we would need 340 bytes of RAM to implement all three new commands, a new rate channel service routine, and the present subcom correction patch. Only about 46% of the available RAM would be needed, thus allowing some margin to remain for unforeseen problems. This is probably enough margin, but an additional 256 bytes of RAM could be added by physically "piggy-backing" two additional TCC244 RAM chips on top of existing parts on the data system board (no spare chip locations remain on the board). It seems prudent to add the extra RAM at this time since we will have to change the RAM chips on the board in the near future anyway.

There is a possible problem with this RAM-patch approach.  We would be adding perhaps 340 bytes of new RAM-based operating system code in series with the old ROM-based code; if the RAM containing the new code should experience a soft (or hard) bit upset, the instrument operating software could "crash," jumping into undefined areas of memory.

Because RAM is much more likely to change than ROM, the more operating code you have in RAM, the more likely the chance this could happen.  The actual risk involved will depend upon the reliability and radiation hardness of the new TCC244 RAMs vs. that of the CD1834 ROMs.

Several things can be done to reduce the effects of this problem. We will use the EPD checksum limit checker to monitor the RAM as well as ROM contents; unfortunately, there is a good chance that should one of the new operating system bytes go bad, the software could crash before the error-flagged checksum is computed.  In addition, we do have the capability of reading out the whole EPD memory contents via the spacecraft CDS interface, even when the EPD data system software is not working.  This capability must be initiated by the spacecraft, however.

We could also implement a "watchdog timer" circuit in the instrument.  This timer is connected so that it initiates a data system power-on-reset if it is not strobed every so often.  The strobing is done via a command that is imbedded in the operating software; if the software becomes "lost," therefore, this strobe is not sent, and a reset is generated.  Such a circuit might be added to the bus adapter board.  Wherever it is added, however, it will represent an additional single point failure, whereas a RAM byte failure can be eventually worked around.  In other words, this is not a clear cut decision.

At this time, no good candidate is available for generating the watchdog strobe in our present flight software. We will continue examining this area, but it is likely that no watchdog timer will be added to the instrument.

In general, the best way to add new software to the instrument is to keep the RAM additions as short as possible.  It may be that further work in this area by H. Malcom will lead to more efficient software changes.

Next: Ground Support Equipment 

QUICK FACTS

RELATED LINKS