Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
The boot code provides the BEP with the capability to 1) boot from the FS ROM; 2) to install code delivered from uplink and to begin executing at a selected location.
The Boot BEP provides the following feature:
The booting of the BEP is normally controlled by ground commands, either a power-on reset, or a discrete commanded reset. The latter command consists of two types, boot from ROM and boot from uplinked command. An abnormal reset, triggered by the watchdog resetting, is expected when there has been an anomalous response from the running software. (1)
During boot, there is no capability for the software to echo commands to the ground. The setting of the BiLevel Discrete Downlink bits (LEDs on non flight boards) is used to indicate progress during the boot process. Their state is periodically sampled by the hardware at predetermined intervals. (2) The software "state" will continue to be reported by the main software after boot has transferred control. Refer to Section 13.6 Discrete Telemetry Status.
The standard mode of operation will use load from ROM. The load from uplinked command is provided to allow ground to take over the BEP for maintenance, for debugging problems, for creating a functionality to perform a task not envisioned when the instrument was designed.
The boot procedure first manages the hardware interface including setting the BiLevel Discrete Downlink bits (LEDs) to indicate a reset, it then determines if a load from uplink is planned. If it is, the ground will have notified the instrument via the hardware command port, and the hardware will have set the BEP status register boot mode bit. If not loading from uplink, a standard boot from ROM will occur. Figure 31 illustrates the flow of control of the BEP boot procedure. The bolded boxes indicate functionality expanded in later figures.
FIGURE 31. BEP Boot Function Flow of Control
When booting from uplink the Uplink Wait LEDs are set, then the procedure will begin a loop which interrogates the FIFO as the commands arrive. During this cycle, the watchdog is handled. As the first command arrives the LEDs will be reset to Uplink Copy, indicating that data is being processed. The function will examine the packet header operation code and extract processing arguments from the command header. Unanticipated command packets will be discarded. The function will determine whether it should load data to memory or should execute code at an assigned address. It will load data to memory, cycling to obtain additional packets of data as necessary. Should the data load request be fulfilled before the last packet is empty, the remainder of that packet's data will be drained from the FIFO. The LEDS will be reset to Uplink Execute showing that execution is beginning. The watchdog will be touched, giving the new process the maximum time before it must handle that task. Should the executing process return, the boot process will branch back to reinitialize the mongoose, and re-examine the BEP Boot Mode state.
The process will read the FIFO until it obtains the first packet word, which will contain the packet total length. It will read and ignore the command identifer, then read the op-code and determine whether it is a Continue_Load or a Start_Load command. Other commands read from the FIFO and ignored. The process will read the align word from the FIFO (TBD). Refer to Figure 32.
FIGURE 32. Read Packet Header With Expected Packet Decision and Read Command Header
A Start_Load command will cause the LEDs to be set to indicate that an Uplink Copy is in progress. It will then read the total count of words to be written into memory and the address where execution is to begin after the data has been loaded. The packet length will be adjusted prior to advancing to a loop which reads the data and writes it to memory.
A Continue Load packet must be preceded by a Start_Load packet. When a Continue_Load command is recognized, the packet length is adjusted for the packet header size, before advancing to read the data and write it to memory. An unexpected packet op-code will result in trashing of that packet and restoration of the Uplink Wait (LED) state which requires a new Start_Load command before a Continue_Load command will be written to memory. An interviening Start_Load command takes presidence, and will load data as directed. This stratigum permits loading data to several locations prior to execution at its target address.
After having read the header, the process proceeds to the decisions concerning processing the remaining data. The total amount of data may have been loaded (including zero words). The amount of data in the packet may have been loaded, else the process will look for another packet. With more data to be loaded, the process will obtain the next word to be installed in memory. Refer to Figure 33. The bolded box indicate functionality expanded in the later figures.
FIGURE 33. Read Packet Data and Write It to Memory
The I-Cache can not be written to directly. D-Cache and general memory can be written directly. To load to I-Cache the data to write, and the address to be written, must be delivered to hardware registers and the write will be accomplished. For this reason, the load address is tested and the data is then loaded in the appropriate manner. The process will return to evaluate the need to read and deposit another word.
After the Total number of words have been loaded, the process will check that the current packet has been emptied, else it will drain the FIFO of the residual words before advancing to begin execution.
Each FIFO word contains 16 bits of data in the low two bytes, in addition to flags in the upper portion. When reading data to load into memory, two packet (FIFO) words are combined to create a single word to load into memory. Refer to Figure 34. The bolded box indicates functionality expanded in a later figure.
The FIFO may or may not have an available word to be read every time one is requested. For this reason the process will attempt to read the FIFO into a register. Then it will touch the watchdog to prevent a reset, and will test the register to determine if a word was transferred. It will continue to cycle until a word is available, then return to the calling function. Refer to Figure 35.
After initializing the mongoose, the process tests the reset status. If the mode indicates boot from FS ROM, control jumps to that ROM. Code within the ROM copies information into I-Cache (code) and D-Cache (data). It will then jump to the execution address. Execution from the FS ROM is not expected to return. Refer to Figure 36.
The Back End's Boot ROM software and main software use the four discrete telemetry bits to indicate the current status of the instrument software. These four bits allow the soft
ware to assign up to 16 different status values. These bits are sampled by the hardware once per Telemetry Major Frame.
The Boot ROM software uses these bits to help a maintainer diagnose lockup problems during Boot. The Boot ROM asynchronously sets these bits to specific values at different
stages during the boot. If the instrument hangs during the boot, the status bits will indicate
which stage caused the hang. The stages and values are assigned as shown in Table 13.
TABLE 13. Boot ROM Discrete Telemetry Value Assignments
------------------------------------------------------------------------------------------- Stage Value Description------------------------------------------------------------------------------------------- Reset 15 The Back End Boot ROM sets the status to this value upon reset of the Back End Processor. This value allows the maintainer to detect a lockup before the Boot ROM had a chance to detect the type of boot to be performed. ROM Copy 14 The Back End Boot ROM sets the status to this value prior to copying code and data from the Back End's Software ROM. This value allows the maintainer to detect a failure while copying code and data from this ROM. ROM Execute 13 The Back End Boot ROM sets the status to this value prior to exe cuting code loaded from the Back End's Software ROM. This value allows the maintainer to detect a lockup when the loaded code is executed. Uplink Wait 12 The Back End Boot ROM sets this value prior to polling the Com mand Interface for an "Start Load From Uplink" command. This value allows the maintainer to determine when the instrument is waiting for code and data from the uplink interface. Uplink Copy 11 The Back End Boot ROM sets this value after receiving the "Start Load From Uplink" command packet. This value allows the main tainer to determine that the instrument has received the first load command, and is in the process of copying its code and data, and waiting for subsequent "Continue Load From Uplink" commands. Uplink Execute 10 The Back End Boot ROM sets this value after receiving and load ing all code and data from the Command Interface, and is about to execute the loaded code. This value allows the maintainer to detect a lockup when the loaded code is executed. -------------------------------------------------------------------------------------------
The loaded Back End software uses the status bits to help a maintainer determine the cur
rent state of the instrument software. During its initialization stage, the Back End software
sets the status bits to specific values to help a maintainer diagnose a hang during the initialization stage. After initialization, the Back End software periodically toggles the status between two values, depending on the current "state" of the software. Table 14 lists the values used by the Back End software.
TABLE 14. Main Software Discrete Telemetry Value Assignments
----------------------------------------------------------------------------------------------- Stage Value(s) Description----------------------------------------------------------------------------------------------- Patch Application 9 The loaded Back End software sets the status bits to this value prior to applying any software patches. This allows the main tainer to determine if the Back End hangs while installing patches. Startup 8 The loaded and patched Back End software sets the status bits to this value prior to executing its module initialization routines. This allows the maintainer to determine if the Back End hangs during its main initialization process. Idle 7,6 The Back End software periodically toggles between these two values, at a TBD rate, while running when a Science Run is not being performed. This allows a maintainer to determine that the instrument is active, but not performing any science operations. Science 5,4 The Back End software periodically toggles the status bits between these two values, at a TBD rate, when executing a Sci ence Run. This allows a maintainer to determine that the instru ment is executing a Science Run. WD Idle 3,2 If the Back End recovers after a Watchdog Reset, the software uses these values when it is in an "Idle" state. This allows a maintainer to determine that a Watchdog Reset occurred. WD Science 1,0 If the Back End recovers after a Watchdog Reset, the software uses these values when it is performing a "Science Run." This allows a maintainer to determine that a Watchdog Reset occurred. -----------------------------------------------------------------------------------------------
Next Chapter