ACIS Users Guide, Rev. A |
ACIS implements all of its memory reads using the Memory Server task. This task is capable of trickling out one contiguous region of memory at a time, using one or more telemetry packets, concurrently with science processing runs and DEA housekeeping runs. In order to prevent erroneously large memory dumps from preventing subsequent dump commands from being executed, all flavors of memory dump commands will abort any dump in progress.
This section describes reads of general areas of memory. For these types of reads, the user must know the type of memory to read, the address of the region to read, and the number of words to read. To see special "tagged" memory reads, where the instrument determines the address and length of the read, see Section 3.6.2.
* acisBepUnix Users: Certain General Memory reads for the Unix simulation, acisBepUnix, won't work the same way. You need to locate the address of interest in acisBepUnix.map, and use that address. In some cases, certain regions, such as the ROM, don't exist on the simulation.
NOTE: In general, any memory read may be aborted by a subsequent memory read, write or execute command.
Description
The user issues a "Read Bep" command to perform a general read of BEP memory, specifying the starting address to read, and the number of 32-bit words to read. Any location in the BEP address space can be read using a "Read Bep" command, with the following constraints:
- The start address must be aligned to a 32-bit word boundary (i.e. evenly divisible by 4)
If not, the command will be rejected, with a CMDRESULT_ARGUMENT in the Com mand Echo "result" field.
- The region being read must not cross an Instruction Cache address boundary These addresses are: 0x80080000 and 0x800fffff. If the region crosses one of these boundaries, the command will be rejected, with a CMDRESULT_ARGUMENT in the Command Echo "result" field.
- If the region is in a FEP shared memory area, the associated FEP must be powered on
The FEP shared memory regions are:
FEP 0 - 0xa8000000 0xa8ffffff FEP 1 - 0xa9000000 0xa9ffffff FEP 2 - 0xaa000000 0xaaffffff FEP 3 - 0xab000000 0xabffffff FEP 4 - 0xac000000 0xacffffff FEP 5 - 0xad000000 0xadffffffIf the FEP does not have power, a BEP Bus Error Exception will be raised and will cause a Fatal Error and subsequent BEP re-boot.
Commands
General read of BEP Memory
readBep: CMDOP_READ_BEP { readAddress = start - Starting Address (must be 32-bit aligned) wordCount = # words - Number of 32-bit words to read }For example, to read the entire contents of the BEP's Data Cache:
readBep: CMDOP_READ_BEP { readAddress = 0x80000000 - Start of D-cache wordCount = 0x10000 - Number of 32-bit words (256Kbytes) }Another example, to read the entire contents of the BEP's Instruction Cache:
readBep: CMDOP_READ_BEP { readAddress = 0x80080000 - Start of I-cache wordCount = 0x20000 - Number of 32-bit words (512Kbytes) }
Science Telemetry
Command Echo of a generic BEP read request:
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) readBep: CMDOP_READ_BEP { readAddress = specified start address wordCount = specified word count } }If the read interrupts an earlier on-going read, the Command Echo "result" field will contain CMDRESULT_CLOBBERED.
If the read attempts to interrupt a Write-Memory or Execute-Memory activity, the read is not performed. In this case, the Command Echo "result" field will contain CMDRESULT_BUSY.
If the address region spans an I-cache boundary, or if the starting address is not aligned to a 32-bit word boundary, the command will be rejected, and the "Command Echo" "result" field will contain CMDRESULT_ARGUMENT.
Once executing, the Memory Server task will produce a series of "BEP Read Reply" telemetry packets of the form:
bepReadReply: TTAG_READ_BEP { commandId = Command Id of read command bepTickCounter = BEP 10Hz Tick counter at start of the read requestedAddress = original specified address requestedWordCount = original specified word count readAddress = start address of data in readData[]. For each but the first packet in the series, this should be the readAddress of the previous telemetry packet plus the number of bytes (i.e. words * 4) in the previous packet's readData[] readData[] = array of read 32-bit words }The Memory Server uses telemetry packet buffers of 1023 32-bit words. The header portion of each "BEP Read Reply" telemetry packet is 7 words, leaving 1016 32-bit data words for each "BEP Read Reply" telemetry packet. Given a "wordCount" for any region of memory, the Memory Server will use the following number of telemetry packets to send that region:
wordCount / (1023 - 7) (+ 1 if wordCount % (1023 - 7) != 0)
Warnings
If, when the command is received, the Memory Server task is executing an earlier read command, such as a dump of the Huffman Tables, the earlier read will be aborted, possibly causing incomplete information to be telemetered. The new read will then commence.
If a Write-Memory command or Execute-Memory command is being executed by the Memory Server task when a read request is received (or even if a new Write-Memory or Execute-Memory command is received), the new command will NOT be executed.
Attempts to read shared memory regions belonging to FEPs which do not have power may result in a BEP Bus Error exception, Fatal Error Message and BEP re-boot.
Description
The ACIS ROM is memory-mapped into the BEP's address space, and is located at memory location 0xbfc00000 and contains 0x40000 32-bit words. To dump the contents of the entire ROM, the user issues a "Read Bep" command, specifying the address and length listed above.
Commands
Command to Read all of ROM:
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) readBep: CMDOP_READ_BEP { readAddress = 0xbfc00000 - Start of BEP ROM wordCount = 0x40000 - # 32-bit words in ROM (1Mbyte) } }If the read interrupts an earlier on-going read, the Command Echo "result" field will contain CMDRESULT_CLOBBERED.
If the read attempts to interrupt a Write-Memory or Execute-Memory activity, the read is not performed. In this case, the Command Echo "result" field will contain CMDRESULT_BUSY.
Once executing, the Memory Server task will produce a series of "BEP Read Reply" telemetry packets of the form:
bepReadReply: TTAG_READ_BEP { commandId = Command Id of read command bepTickCounter = BEP 10Hz Tick counter at start of the read requestedAddress = 0xbfc000000 requestedWordCount = 0x40000 readAddress = start address of data in readData[]. For each but the first packet in the series, this should be the readAddress of the previous telemetry packet plus the number of bytes (i.e. words * 4) in the previous packet's readData[] readData[] = array of read 32-bit words }
Warnings
See Section 3.6.1.1 Warnings
Description
The user issues a "Read Fep" command to perform a general read of FEP memory, specifying the FEP, the starting address to read, and the number of 32-bit words to read. Any location in the FEP address space can be read using a "Read Fep" command, with the following constraints:
- The start address must be aligned to a 32-bit word boundary (i.e. evenly divisible by 4)
If not, the command will be rejected, with a CMDRESULT_ARGUMENT in the Command Echo "result" field.
- The region being read must not cross an Instruction Cache address boundary
These addresses are: 0x80080000 and 0x800fffff. If the region crosses one of these boundaries, the command will be rejected, with a CMDRESULT_ARGUMENT in the Command Echo "result" field.
- The FEP must be powered when the read command is received
Attempts to read from a FEP when the FEP is not powered will cause the read to be rejected. The Command Echo result field will be set to CMDRESULT_BOARD_OFF.
- The FEP must remain powered during the read
Attempts to read a FEPs memory when the FEP is not powered may cause the read to abort, or possibly cause a BEP Bus Error Exception, which will subsequently cause a Fatal Error and BEP re-boot.
Commands
General read of FEP Memory
readFep: CMDOP_READ_FEP { fepId = FEP_0..FEP_5 - FEP to read from readAddress = start - Starting Address (must be 32-bit aligned) wordCount = # words - Number of 32-bit words to read }For example, to read the entire contents of the FEP 3's Data Cache:
readFep: CMDOP_READ_FEP { fepId = FEP_3 - Read from FEP 3 readAddress = 0x80000000 - Start of D-cache wordCount = 0x10000 - Number of 32-bit words (256Kbytes) }Another example, to read the entire contents of the FEP 5's Instruction Cache:
readFep: CMDOP_READ_FEP { fepId = FEP_5 - Read from FEP 5 readAddress = 0x80080000 - Start of I-cache wordCount = 0x20000 - Number of 32-bit words (512Kbytes) }
Science Telemetry
Command Echo of a generic FEP read request:
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) readFep: CMDOP_READ_FEP { fepId = specified FEP readAddress= specified start address wordCount = specified word count } }If the read interrupts an earlier on-going read, the Command Echo "result" field will contain CMDRESULT_CLOBBERED.
If the read attempts to interrupt a Write-Memory or Execute-Memory activity, the read is not performed. In this case, the Command Echo "result" field will contain CMDRESULT_BUSY.
If the address region spans an I-cache boundary, or if the starting address is not aligned to a 32-bit word boundary, the command will be rejected, and the "Command Echo" "result" field will contain CMDRESULT_ARGUMENT.
If an attempt is made to read from a FEP whose power is off, the command will be rejected and the Command Echo "result" field will contain CMDRESULT_BOARD_OFF.
Once executing, the Memory Server task will produce a series of "FEP Read Reply" telemetry packets of the form:
fepReadReply: TTAG_READ_FEP { commandId = Command Id of read command fepId = original specified FEP bepTickCounter = BEP 10Hz Tick counter at start of the read requestedAddress = original specified address requestedWordCount = original specified word count readAddress = start address of data in readData[]. For each but the first packet in the series, this should be the readAddress of the previous telemetry packet plus the number of bytes (i.e. words * 4) in the previous packet's readData[] readData[] = array of read 32-bit words }The Memory Server uses telemetry packet buffers of 1023 32-bit words. The header portion of each "FEP Read Reply" telemetry packet is 7 words, leaving 1016 32-bit data words for each "FEP Read Reply" telemetry packet. Given a "wordCount" for any region of memory, the Memory Server will use the following number of telemetry packets to send that region:
wordCount / (1023 - 7) (+ 1 if wordCount % (1023 - 7) != 0)
Warnings
See Section 3.6.1.1 Warnings
Attempts to read FEP memory from FEPs which do not have power may result in a BEP Bus Error exception, Fatal Error Message and BEP re-boot.
The BEP implements FEP read requests to shared memory regions by just reading the memory directly. This may affect the performance of on-going science by stealing bus cycles away from the FEP.
The BEP implements FEP read requests to non-shared memory regions by issuing requests to the FEP via the BEP-to-FEP software mailbox. This may interfere with the performance of on-going science by actively requesting interactions with the software running on the FEP. These types of reads also require that the FEP software be up-and running, and will time-out if the FEP software has crashed or if the FEP is held in a reset state.
The FEP hardware cannot reliably handle science data processing and BEP requests to read bias-memory and threshold or parity plane simultaneously. This may cause writes of the hardware to the threshold plane and parity planes to cease, causing loss of science data from the affected FEP. A reset of the FEP is required to recover from this condition, and FEPs are only routinely reset when they are power-cycled, are re-loaded at the start of a science run after a FEP crash, or when a science run is aborted due to the radiation monitor.
Description
The DEA Video Boards contain two types of readable RAM: Sequencer RAM (SRAM) and Program RAM (PRAM). When the sequencers aren't running, the user can issue a "Read SRAM" command to perform a general read of Video Board Sequencer memory, specifying the CCD associated with the board (see Section 3.3.4 ), the starting address to read, and the number of 16-bit words to read. To read a board's Program RAM, the user can issue a "Read PRAM" command. These commands can only be issued under the following conditions:
- The selected Video Board must be powered
Attempts to read from a Video Board when the board is not powered will cause the read to be rejected. The Command Echo result field will be set to CMDRESULT_BOARD_OFF.
- The sequencers must be idle
If a science or bias run is in progress when a read is requested, or starts while a read request is active, the read will be aborted. This is reflected in Software Housekeeping with a SWSTAT_DEABOARD_ERROR entry.
Note: PRAM/SRAM contain trash until a science run. The contents of a video board's SRAM and PRAM are undefined until the first science run after the video board has been powered on, or until a "Write PRAM" or "Write SRAM" command is received which loads their contents.
Commands
Read SRAM
readSram: CMDOP_READ_SRAM { ccdId = I0..S5 - Selects which video board to read from readIndex = 0..0x7fff - Starting SRAM address wordCount = 0..0x8000 - Number of 16-bit words to read }Read PRAM
readPram: CMDOP_READ_PRAM { ccdId = I0..S5 - Selects which video board to read from readIndex = 0..0x7fff - Starting PRAM address wordCount = 0..0x8000 - Number of 16-bit words to read }For example, the command to dump all of CCD I3's PRAM is as follows:
readPram: CMDOP_READ_PRAM { ccdId = I3 readIndex = 0 wordCount = 0x8000 }
Science Telemetry
Command Echo of a generic SRAM read request:
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) readSram: CMDOP_READ_SRAM { ccdId = specified Video Board readIndex = specified start index wordCount = specified word count } }Command Echo of a generic PRAM read request:
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) readFep: CMDOP_READ_PRAM { ccdId = specified Video Board readIndex = specified start index wordCount = specified word count } }If the read interrupts an earlier on-going read, the Command Echo "result" field will contain CMDRESULT_CLOBBERED.
If the read attempts to interrupt a Write-Memory or Execute-Memory activity, the read is not performed. In this case, the Command Echo "result" field will contain CMDRESULT_BUSY.
If the address region spans an I-cache boundary, or if the starting address is not aligned to a 32-bit word boundary, the command will be rejected, and the "Command Echo" "result" field will contain CMDRESULT_ARGUMENT.
If an attempt is made to read from a Video Board whose power is off, the command will be rejected and the Command Echo "result" field will contain CMDRESULT_BOARD_OFF.
Once executing, the Memory Server task will produce a series of "SRAM Read Reply" or "PRAM Read Reply" telemetry packets of the form:
sramReadReply: TTAG_READ_SRAM { commandId = Command Id of read command ccdId = original specified Video Board bepTickCounter = BEP 10Hz Tick counter at start of the read requestedIndex = original specified index requestedWordCount = original specified word count readIndex = start address of data in readData[]. For each but the first packet in the series, this should be the readIndex of the previous telemetry packet plus the number of bytes (i.e. words * 2) in the previous packet's readData[] readData[] = array of read 16-bit words } pramReadReply: TTAG_READ_PRAM { commandId = Command Id of read command ccdId = original specified Video Board bepTickCounter = BEP 10Hz Tick counter at start of the read requestedIndex = original specified index requestedWordCount = original specified word count readIndex = start address of data in readData[]. For each but the first packet in the series, this should be the readIndex of the previous telemetry packet plus the number of bytes (i.e. words * 2) in the previous packet's readData[] readData[] = array of read 16-bit words }Since an odd number of 16-bit words may be requested, except for the last, all readData[] fields in a series of telemetry packets will be filled out to an even number of 16-bit words. The last packet may contain an odd number, although the length of the telemetry packet is always 32-bit aligned. The user determines the length of the last readData[] array by relying on the requestedWordCount.
The Memory Server uses telemetry packet buffers of 2046 16-bit words. The header portion of each "SRAM/PRAM Read Reply" telemetry packet is 11 16-bit words, leaving 2035 16-bit data words for each "SRAM/PRAM Read Reply" telemetry packet. Given a "wordCount" for any region of SRAM/PRAM, the Memory Server will use the following number of telemetry packets to send that region:
wordCount / (2046 - 11) (+ 1 if wordCount % (2046 - 11) != 0)
Warnings
See Section 3.6.1 Warnings
ACIS contains certain memory regions containing data structures which are necessary for interpreting the science data. All of this information can be determined by the commanding sequence. However, to ease the burden on the ground system, the ACIS software packages dumps some of these regions using distinct commands and telemetry format tags. The actual form of the telemetry packet data is the same as for the memory reads described in Section 3.6.1.1.
Description
ACIS maintains one Bad Pixel Map, a Timed Exposure Bad Column Map and a Continuous Clocking Bad Column Map (see Section 3.5 ). The user can telemeter the contents of these maps by issuing "Dump Bad Pixels", "Dump Bad Te Column Map" and "Dump Bad Cc Column Map" command packets, respectively.
Commands
Dump Bad Pixel Map
dumpBadPixels: CMDOP_DUMP_BAD_PIXELS { No additional Parameters }Dump Timed Exposure Bad Column Map
dumpBadTeColumnMap: CMDOP_DUMP_BAD_TE_COL { No additional Parameters }Dump Continuous Clocking Bad Column Map
dumpBadCcColumnMap: CMDOP_DUMP_BAD_CC_COL { No additional Parameters }
Science Telemetry
Command Echo of a generic "Dump" request, where the "echoed command" is substituted for each type of dump.
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) dumpBadPixels: CMDOP_DUMP_BAD_PIXELS { } }The constraints and error codes for a dump command are the same as those for a general "Read Bep" command (see Section 3.6.1.1 Science Telemetry), although a result of CMDRESULT_BAD_ARGUMENT indicates a problem within the instrument, rather than a commanding error.
The overall form of the telemetry Bad Pixel Map and Bad Column Map packets are the same as those for a "Read Bep" command (see Section 3.6.1.1 Science Telemetry), except the telemetry format tags are unique for each type of table.
The format of the Bad Pixel Map (formatTag = TTAG_DUMP_BAD_PIXEL) data is an array of 32-bit entries, where each entry has the form:
bits 0..3 = I0..S5 - CCD containing the bad pixel bits 4..13 = 0..1023 - CCD Row Location of the pixel bits 14..23 = 0..1023 - CCD Column Location of the pixel bits 24..31 = unusedThe format of the Bad Column Map (formatTag = TTAG_DUMP_BAD_TE_COL or TTAG_DUMP_BAD_CC_COL) data is an array of packed 16-bit words. Although each column is represented using 1 16-bit word, the read will always telemeter data in an array of 32-bit words. If there are an odd number of bad column entries, the last dumped item will contain zeros for all fields.
bits 0..3 = I0..S5 - CCD containing the bad column bits 4..13 = 0..1023 - CCD Column Location bits 13..15 = unused
Warnings
See Section 3.6.1.1 Warnings
The number of columns is ambiguous when dumping a table containing an odd number of bad columns and when the last entry in the list has the values (CCD = I0 ccdColumn = 0).
Description
ACIS maintains its parameter blocks in sets of arrays of "slots." Each type of parameter block has a distinct set of slots. Each set contains 5 slots, and each slot is 512 bytes in length (NOTE: All parameter block types are 512 bytes or less in length). In order to verify the contents of the parameters, independently of any science runs, ACIS provides distinct commands to dump the contents of each set of slots using "dumpParameterSlots" command packets, where the command opcode discriminates between the different slot types. Since the number of bytes in an entire set of slots (including overhead) is less in size than a single telemetry packet, each set of slots is telemetered in a single "BEP Read Reply" telemetry packet, where the slot type is indicated using different telemetry format tags:
Timed Exposure Parameter Blocks - CMDOP_DUMP_TE_SLOTS - TTAG_DUMP_TE_SLOTS Continuous Clocking Parameter Blocks - CMDOP_DUMP_CC_SLOTS - TTAG_DUMP_CC_SLOTS 2-D Window Parameter Block - CMDOP_DUMP_2D_SLOTS - TTAG_DUMP_2D_SLOTS 1-D Window Parameter Block - CMDOP_DUMP_1D_SLOTS - TTAG_DUMP_1D_SLOTS DEA Housekeeping Parameter Blocks - CMDOP_DUMP_DEA_SLOTS - TTAG_DUMP_DEA_SLOTSNOTE: Be careful not to confuse memory slot dumps with parameter dumps automatically performed at the start of each science run. The purpose and formats of the packets are different (the later contains just the slots used for the run, not the entire set of 5 slots).
Commands
Command to dump all of the stored Timed Exposure Parameter Block slots:
dumpParameterSlots: CMDOP_DUMP_TE_SLOTS { No additional parameters required }Command to dump all of the stored Continuous Clocking Parameter Block slots:
dumpParameterSlots: CMDOP_DUMP_CC_SLOTS { No additional parameters required }The other types of slots are dumped in a similar fashion by substituting the CMDOP_* used to request the dump.
Science Telemetry
Command Echo of a generic "Dump" request, where the opcode of the "echoed command" is substituted for each type of dump.
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) dumpParameterSlots: CMDOP_DUMP_*_SLOTS { } }The overall format of the read-reply telemetry packet is identical to that in Section 3.6.1.1. However, the telemetry format tag will reflect the type of slot set being telemetered. The resulting data array will consist of five 512-byte slots, with a parameter block of the specified type aligned to start at the beginning of each slot. The format of a given parameter block type is identical to the command format used to load that type of block.
Warnings
See Section 3.6.1.1 Warnings
A common misconception about ACIS is that any type of parameter block can go into any slot. THIS IS FALSE. Each type of parameter block has its own distinct set of slots. One cannot store a Continuous Clocking Parameter Block (well, not by accident at least) in a Timed Exposure Parameter Block Slot.
The parameter block slots are always 512-bytes in length, although the parameter blocks themselves may be shorter. This leaves gaps between the parameter blocks in the dumped telemetry data filled with random data.
Description
ACIS uses a fixed-table Huffman compression scheme to compress telemetered bias maps and raw CCD images. ACIS maintains an array of selectable compression tables using a data structure. This structure consists of a header, which is an array of 32 table offset values, followed by a data array of 32-bit words. The data array contains the compression tables themselves. The offsets in the header are indexed by a "compression table slot". Each offset identifies the start of each compression table within the data array, in terms of 32-bit words relative to the end of the header. If an offset is set to 0xffffffff, then there is no compression table associated with that compression table slot.
The software provides a command which dumps the contents of this data structure, "Dump Huffman". When this command is received, the Memory Server tasks telemeters the raw contents of this entire data structure in a series of "Bep Read Reply" telemetry packets, tagged with the TTAG_DUMP_HUFFMAN format tag.
Commands
Command to dump the Huffman Table data structure
dumpHuffman: CMDOP_DUMP_HUFFMAN { No additional parameters required }
Science Telemetry
Command Echo of a "Dump Huffman" request
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) dumpHuffman: CMDOP_DUMP_HUFFMAN { } }The overall format of the read-reply telemetry packet is identical to that in Section 3.6.1.1, except the telemetry format tag will be set to TTAG_DUMP_HUFFMAN. The resulting data array will consist of an array of 32 4-byte offset values, followed by a raw data array of 8197 32-bit data words. The bit-level format of the compression tables themselves is described in Huffman Coding of ACIS Pixel Data (MIT-CSR 36-56102)
The number of telemetry packets that will be sent is:
(32 offsets + 8197 data words)/(1023 words/pktbuf-7 header words) = 9 packetsNOTE: A common error when running the instrument "by-hand" is to forget that the Huffman tables require more than 1 telemetry packet to send, and to issue a dump command for another item before the Huffman Table has been completely sent.
Warnings
See Section 3.6.1.1 Warnings
A common error when manually commanding ACIS is to not leave enough time for the Huffman Table dump to complete prior to issuing the next dump command. At 24Kbps (format 2), this will take about 13 seconds, and at 500 bps (all other formats), it will take about 10 minutes.
Commands
Command to dump the PatchList
dumpPatchlist: CMDOP_DUMP_PATCHLIST { No additional parameters required }
Science Telemetry
Command Echo of a "Dump Patchlist" request
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) dumpHuffman: CMDOP_DUMP_PATCHLIST { } }The overall format of the read-reply telemetry packet is identical to that in Section 3.6.1.1, except the telemetry format tag will be set to TTAG_DUMP_PATCHES.
The patch nodes are stored in reverse order in memory, with the first word of the data structure at location 0x800ffffc. The last byte location in the dump will always be:
(requestedAddress + requestedWordCount) = 0x800ffffcThe easiest way to parse the patch list data is to start from the end of the dumped data, and work backwards towards the beginning. The sent data format, indexed as 32-bit words, is as follows, where RWC is the requestedWordCount field in the "BEP Read Reply" telemetry packets:
etc. /* END OF NODE 1 */ (RWC - 5 - wordCount0 - 3 - wordCount1 + 1) through (RWC - 5 - wordCount0 - 3): data[wordCount1] - Patch Data (RWC - 5 - wordCount0 - 2): wordCount1 - # 32-bit words in Patch Node (RWC - 5 - wordCount0 - 1): dstAddress - Destination Address of Patch (RWC - 5 - wordCount0): patchId - 32-bit Patch Identifier /* START OF NODE 1 */ /* END OF NODE 0 */ (RWC - 5 - wordCount0 + 1) through (RWC - 5): data[wordCount0] - Patch Data (RWC - 4): wordCount0 - # 32-bit words in Patch Node (RWC - 3): dstAddress - Destination Address of Patch (RWC - 2): patchId - 32-bit Patch Identifier /* START OF NODE 0 */ /* CHECKSUM */ (RWC - 1): 32-bit wide XOR checksum of bolded regionNOTE: The size of the dump depends on the number of nodes in the patchlist and the size of the data area in each node. Currently, the upper bound is the amount of space remaining in Instruction Cache after the Bad Pixel Map, which is currently TBD bytes. This upper bound may vary, however, if the system is patched to use some of the Bad-Pixel Map space for additional patches. For simplicity, one can always rely on the absolute upper bound, which is the size of Instruction Cache (512Kbytes).
NOTE: The stored on-board pointer to the end of the list (i.e. where to put the next patch node) is not telemetered in the dump. If needed, this field can be read using a "Read BEP" command, using 0x800ffffc as the readAddress, and 1 as the wordCount. The read should be 4-bytes less than the requestedAddress field produced by the dumped patchlist "BEP Read Reply" packets.
0x800ffffc: where to write the next patch node
Warnings
See Section 3.6.1.1 Warnings
The size of a Patchlist Dump depends on the number of patch nodes (3 32-bit words of header per node) and the amount of data stored in each node.
Because the patch nodes are stored in RAM from high-memory to low-memory, the node headers follow their respective data arrays, and the data arrays are variable in length, the end of the patchlist dump must be received to interpret nodes preceding it in memory. It is difficult to interpret nodes prior to any telemetry outages or corruptions in the patchlist dump.
Description
In order to dump the contents of the ACIS System Configuration Table (see Section 3.3), the user issues a "Dump SysConfig" command packet. Upon receipt of the command, the Memory Server task telemeters the table using a single "BEP Read Reply" telemetry packets, tagged using the TTAG_DUMP_SYS_CONFIG telemetry format tag.
Commands
Command to dump the System Configuration Table
dumpSysConfig: CMDOP_DUMP_SYS_CONFIG { No additional parameters required }
Science Telemetry
Command Echo of a "Dump SysConfig" request
commandEcho: TTAG_CMD_ECHO { arrival = time command arrived (BEP 10Hz Ticks) result = CMDRESULT_OK (other values indicate an error) dumpHuffman: CMDOP_DUMP_SYS_CONFIG { } }The overall format of the read-reply telemetry packet is identical to that in Section 3.6.1.1, except the telemetry format tag will be set to TTAG_DUMP_SYS_CONFIG.
The format of the data portion of the dump consists of an array of 16-bit words. The first two words contain a 32-bit checksum of the table. The remaining words are indexed by the system configuration item identifiers, SYSSET_*, used to modify the table (see Section 3.3).
Warnings
See Section 3.6.1.1 Warnings
Because video board parameters are loaded into the DEA upon starting a science run, the video board items in the dumped System Configuration table reflect what is is in the table, but not necessarily what is currently loaded into the CCDs video boards.