[PREVIOUS] [NEXT] [CONTENTS] ACIS Users Guide, Rev. A [AXAF]

3.6 Memory Dumps

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.

3.6.1 General Memory Reads*

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.

3.6.1.1 BEP Memory Read

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:

If 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

  1. Aborts earlier read

    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.

  2. Ignored if Write-Memory or Execute-Memory being performed

    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.

  3. Fatal Errors due to reads of un-powered FEP shared memory

    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.

3.6.1.2 ROM Memory Read

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

  1. See Section 3.6.1.1 Warnings

3.6.1.3 FEP Memory Read

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:

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

  1. See Section 3.6.1.1 Warnings

  2. Reads from Powered Off FEPs may reset BEP

    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.

  3. Shared Memory Reads are direct

    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.

  4. Non-shared Memory Reads need help from 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.

  5. Don't read Bias/T-plane/P-plane during a Science Run

    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.

3.6.1.4 DEA Video Board Memory Read

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:

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

3.6.2 Memory Reads Tagged by Context

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.

3.6.2.1 Bad Pixel and Column Maps

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   = unused

The 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

  1. See Section 3.6.1.1 Warnings

  2. Odd number of columns confusing

    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).

3.6.2.2 Parameter Block Slots

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_SLOTS

NOTE: 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

  1. See Section 3.6.1.1 Warnings

  2. Each type of parameter block has its own set of slots

    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.

  3. Each slot is always 512 bytes in length

    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.

3.6.2.3 Huffman Table

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 packets

NOTE: 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

  1. See Section 3.6.1.1 Warnings

  2. Huffman Tables take 9 packets to dump

    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.

3.6.2.4 Patch List

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) = 0x800ffffc

The 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 region

NOTE: 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

  1. See Section 3.6.1.1 Warnings

  2. Size of Patchlist Dump will vary

    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.

  3. Entire dump required to interpret

    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.

3.6.2.5 System Configuration Table

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

  1. See Section 3.6.1.1 Warnings

  2. Video Boards are only loaded upon start of science run

    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.


[PREVIOUS] [NEXT] [CONTENTS]
James E. Francis
Last modified: Wed Jan 12 10:53:39 EST