Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
This section refines the description of the various Boot-Modes and actions provided by the flight instrument. This section is taken from the Beta Flight Software Release Notes and explains the various ways in which the Back End Processor is initialized at startup.
The following only describes the various ways in which the Back End Processor software is loaded from EEPROM (see Section 3.2.13 for a description of loading the BEP from the uplink channel).
The following is a summary of the flags and actions used to load and start the ACIS Flight Software. The `*' and `+' characters listed in the actions refer to notes after the table:
----------------------------------------------------------------------- action commanded reset watchdog reset bootmodifier warmboot ----------------------------------------------------------------------- power-on off off off off cold-boot on off off off cold-watchdog off on off off uplink on off on off uplink off on on off warm-boot on off off on watchdog-boot off on off on uplink on off on on uplink off on on on uplink+ on on on on cold-watchdog+ on on off off uplink+ on on on off watchdog-boot+ on on off on uplink* off off on off power-on* off off off on uplink* off off on on -----------------------------------------------------------------------
+: Appendix C of the Rev. C of the hardware specification (MIT 36-02104) indicates that a commanded reset clears the watchdog status bit, and that a watchdog reset clears the commanded reset status bit. Table 4 in Section 2.1.2.3.6.2, however, indicates the software must explicitly clear these bits. The described action is that taken by the Flight Software in the unlikely event both the commanded and watchdog reset status bits are on when the system is initialized.
*: Appendix C of the Rev. C hardware specification indicates that the bootmodifier and warmboot flags are zeroed by the hardware on a power-on reset (i.e. commanded reset and watchdog reset are 0). The described action is that taken by the Flight Software in the unlikely event both the commanded and watchdog reset status bits are off and either the bootmodifier or warmboot flags are on when the system is initialized.
This type of boot is caused by asserting the BEP's "bootmodifier" and resetting the BEP. This type of boot is also described in Section 3.2.13.
Once the BEP is reset, the BEP's loader, running from EEPROM, will poll the uplink FIFO for a "Start Upload" command packet. Once the packet is received, the BEP extracts the load address, total number of words in the load, and the execution address from the packet. It will then copy the remainder of the command packet into the specified address. If more data is required, the BEP waits for one or more "Continue Upload" command packets, and appends their contents to the previously copied image in BEP RAM. The BEP will continue this until the total number of words have been loaded, or until aborted by another "Start Upload" command is received. Once the entire image has been loaded into RAM, the BEP jumps to the code located at the indicated execution address.
Further interpretation of the boot control flags (other than the bootmodifier flag) is up to the program loaded from the uplink channel.
This type of boot is caused by power-cycling the BEP. A power-on of the BEP causes the hardware to de-assert the BEP's "bootmodifier" and "warmboot" status bits. The hardware indicates a power-on reset to the BEP by de-asserting both the "watchdog-reset" and "commanded-reset" status bits.
A power-on boot performs the following actions:
1. The loader executing from EEPROM copies code and data from EEPROM into I-cache and D-cache RAM, and jumps to the loaded code. The loaded code in RAM then performs the remaining actions.
2. Reset the patchlist (eliminate all patches from the list)
3. Copy the default tables from EEPROM into I-cache, overwriting any previously stored tables. These tables include:
4. Issue startup message and continue with the startup procedure
5. Once loaded and running, the instrument will idle, waiting for commands
This type of boot occurs when the BEP is commanded to reset (as opposed to powered-on-reset or watchdog-reset), and its "bootmodifier" and "warmboot" status bits are in a deasserted state.
The operator can clear the "bootmodifier" status bit by issuing a hardware serial digital command (see the DPA Hardware Functional Description and Requirements). Using the "buildCmds" program (MIT 36-60302.01), the operator can generate a command to de-assert the bit by typing:
The operator can clear the "warmboot" status bit by issuing a hardware serial digital command (see the DPA Hardware Functional Description and Requirements). Using "buildCmds", the operator can generate a command to de-assert the bit by typing:
To issue a commanded reset, the operator must first assert the BEP's reset line and then release the BEP's reset line. Using "buildCmds", type:
The actions taken by the BEP for a cold boot are identical to that taken by a Power-On Boot (see the description above).
This type of boot occurs when the BEP is commanded to reset (as opposed to powered-on-reset or watchdog-reset), and its "bootmodifier" bit is deasserted but its "warmboot" status bit is asserted.
The operator can use "buildCmds" to assert the "warmboot" status bit by typing the following:
The operator can then issue a commanded reset as described above for a Cold Boot.
The actions taken by the BEP for a warm boot are as follows:
1. Copy code and data from EEPROM into I-cache and D-cache RAM
2. Apply the patches in the patchlist to the copied code and data.
3. Issue startup message and continue with the startup procedure
4. Once loaded and running, the instrument will wait for commands
Note that any table changes made prior to the reset will persist.
This type of boot occurs when the BEP has been unexpectedly reset by its watchdog timer, and the "warmboot" flag is deasserted. The hardware indicates this type of reset to the BEP software by setting the "watchdog reset" status bit, while the "warmboot" status bit is in a deasserted state.
The actions taken by the BEP for a cold watchdog boot are identical to that taken for a power-on boot or a cold boot.
This type of boot occurs when the BEP has been unexpectedly reset by its watchdog timer, and the "warmboot" flag is asserted. The hardware indicates this type of reset to the BEP software by setting the "watchdog reset" status bit, while the "warmboot" status bit is in an asserted state.
The actions taken by the BEP for a warm watchdog boot are as follows:
1. Copy code and data from EEPROM into I-cache and D-cache RAM (undoing patches applied during previous resets)
2. Issue startup message and continue with the startup procedure
3. Once loaded and running, the instrument will wait for commands
Note that after a warm watchdog reset, the patchlist is not destroyed, it is just not applied to the code and data reloaded from EEPROM. A subsequent commanded reset will cause the patches to be re-applied. Also, note that changes made to the tables prior to the reset will remain intact.
TABLE 85. Boot Action Summary