|3||6/5/1900||Art Rankin||Change comment in command reception task to state that the ICD command rate must be adhered to, otherwise the condition of reading before writing could exist. If ICD rate met, then this condition should NOT exist.||Daniel Blackman||Comment added to CHECKGP comment block||CLOSED|
|4||6/5/1900||Rob Lampereur||The CheckRXD Flag has been moved to the background activity, only because Daniel wanted to support FASTER commanding than has been documented that we need to support.
Put into your comments why this has been moved into the background routine.
|Daniel Blackman||Comment added to BACKGROUND comment block||CLOSED|
|6||6/5/1900||Chris Dorato||The comment used elsewhere should be replaced with an explanation of why it is done - explain why the PUSH and POP registers are done in the CHECKRXDFLAG subroutine.||Daniel Blackman||'used elsewhere' removed from comments, replaced with seemly more meaningful comments.||CLOSED|
|7||6/5/1900||Will Clement||Add comments to sections of code that do a check on the project, and make sure it is clear what is the FLIGHT configuration. Also, if code is ONLY for test - make sure it says so.
Also, on line 4132 of EXECUTIV.LST, correct comment error.
|Daniel Blackman||Various bench and test compiler directives now exist to differentiate FLIGHT configuration. Further, this methodology means non-flight code will not be burned into FLIGHT PROM.
Fixed comment error in re: 'EX1'
|8||6/5/1900||Chris Dorato||Document, at a minimum, in the five files, what are the key names/concepts from previous programs that are used in the comments. e.g., FUSE, IDS, GALEX, 1553, DPU, etc...
These concepts should be described in a banner message in the front of each file.
|Daniel Blackman||The list has been started in the commands.inc file, which is read by all source files.||CLOSED|
|9||6/5/2000||Michelle Troeltzsch||Put comments in table definitions within the Patchable constants file.||Daniel Blackman||A basic comment added to TABLE definitions in PATCHCST.a51 file.||CLOSED|
|10||6/5/1900||Allison Elliot||Change comment at 3792 t(of EXECUTIVE.LST) to note that sending only changed values of HSK pertains only to GALEX. COS will transmit the entire packet every time.||Daniel Blackman||Comment added to routine SENDHKP.||CLOSED|
|11||6/5/1900||Will Clement||Make SPARE_CODE label parameters be the difference of two variables, which the assembler computes... rather than having a hard-coded value.
See floppy and hardcopy of code from Will C.
|Daniel Blackman||Sorry, can't do with A51 v5.02 I called Archimedes about it, and they tell me I already have the latest version. The Franklin code example produces an error with the Archimedes A51 assembler.||CLOSED|
|13||6/5/1900||Michelle Troeltzsch||Any comments and more importantly, actually 8051 code, referring to the 1553 interface used on FUSE should be updated for the COS communications protocol.||Daniel Blackman||References to 1553 have been removed from the a51 files, references remain in common.inc, but include banner message describing legacy of 1553 communications from FUSE program.||CLOSED|
|18||6/5/1900||Daniel Blackman||Update comment in UPDATE_CTRS in EXECUTIV.LST. The Comment, 'Timer??? I think...' is not descriptive enough.||Daniel Blackman||Comments rewritten.||CLOSED|
|19||6/5/1900||Michelle Troeltzsch||When reading the counters and the PHD, add comments that you are zeroing the memory after you read them.
||Daniel Blackman||Comments added.
|21||6/5/1900||Will Clement||Revise the format of the Jump Table. See code on floppy disk and hardcopy from Will C.||Daniel Blackman||Jump Table format is completely redesigned, but not quite the way Will had specified. JMPs were completely eliminated to create a lookup table of command subroutine entry-points. The CHECK_COMMAND routine in commands.a51 was changed to fetch the subroutine address and jump there. The PROJECT bit is used to select the command table, allowing separate command tables for GALEX and COS. The RET instruction at the end of every command subroutine returns control to the MAINLOOP caller.||CLOSED|
|25||6/6/1900||Rob Lampereur||Line 3380 of INITIALZ.LST. Add comments that this section of code ONLY executes for development builds. When it is compiled for flight, INIT_TO will have a value such that the LOAD_RAM_CODE is NEVER executed.||Daniel Blackman||This is actually achieved during the link/locate phase. The code build process creates four flavors of FSW: boot-mode image, boot-to-operate-mode image, lower upload image, and upper upload image. By selecting the boot-mode image to create PROMs, this code will perform as required. The boot-to-operate image meets GALEX requirements, and both lower and upper upload images are suitable for GALEX or COS. There is a bit in housekeeping that indicates we are in Boot or Operate mode.||CLOSED|
|27||6/6/1900||Art Rankin||Move the LOAD_RAM_CODE - for development only - to the last part of the Initialize sequence. Even though we will never do this in operations, the early hardware development would benefit by execution in a fashion that is more like how we will operate the detector.
*** IGNORE *** After further discussion, it was realized that this is NOT possible, given that the code image Daniel was referring to REQUIRES operation out of the RAM area.
|Daniel Blackman||Ignored as specified.||CLOSED|
|28||6/6/1900||Ken Brownsberger||Line 4392 of COMMANDS.LST
Add comment in front banner that CDC is really referring to TDCs. We are not flying CDCs in the FUV Detector.
Also, add comment here that you are initializing the three-wire interface for the Digitizers.
|Daniel Blackman||Comments added as requested.
Also, comments added in COMMON.INC
|30||6/6/1900||Daniel Blackman||Line 4385, COMMANDS.LST
Strike comment about I wonder if we should do this.
|Daniel Blackman||Comments struck. The sentiment remains.||CLOSED|
|33||6/6/1900||Allison Elliot||The Watchdog should be disabled after ALL resets, not just a POR.||Daniel Blackman||Acquiescence. See Item 26.||CLOSED|
|35||6/6/1900||Ken Brownsberger||Since the PROM OFF functionality has been removed, remove the IVTINDIR at line 3037 of INITIALZ.LST
Also, the IVTPATCH and IVTINDIR on line 4626 of EXECUTIV.LST. Are these needed?
Consensus is that we shouldnt be running BOOT CODE ISRs out of RAM. Execute the BOOT code out of PROM.
|Daniel Blackman||The programmer does not agree, but may acquiesce later with the same understanding as Item 26. Not done yet, until the programmer is sure the review board fully understands that ISRs cannot be changed in flight, if this action is implemented as is.
*** Recommend this topic is discussed and a formal decision reached and documented at the next code walk-thru. -KRB ***
It is okay for the IVTINDIR to load the ISR jump table into RAM for BOOT and OPERATE.
|37||6/6/1900||Rob Lampereur||Line 3406 of INITIALZ.LST
Change comment from Hang the processor, to Simulate a hung processor by not stroking the watchdog for 10 seconds.
|Daniel Blackman||Comments added.||CLOSED|
|38||6/6/1900||Ken Brownsberger||CHECKBREADBOARD, at line 2965 of INITIALZ.LST
Do NOT check hardware, and then determine flight software functionality based on this check...
COS behavior should be burned into PROM, and we should be guaranteed COS behavior. (See previous AI.)
|Daniel Blackman||Removed CHECKBREADBOARD from code||CLOSED|
|40||6/6/1900||Rob Lampereur||The Initialization of the CRP task, and setting the HV Status Bits needs to be added to the Initialization sequence. They are currently baselined for the design, but have not been included into the code. (e.g., See Fig 4.2-1 of SDD)||Daniel Blackman||Done||CLOSED|
|42||6/6/1900||Ken Brownsberger||Possibly remove INIT_TEST_BKGRND, at line 3035 of INITIALZ.LST - as were not going to do any Background activity in Reset Initialization. It is called in REENTRY anyway.||Daniel Blackman||Done||CLOSED|
|43||6/6/1900||Michelle Troeltzsch||Remove CLR EA, at line 4557 in EXECUTIV.LST. As we just finished calling it at 4545.||Daniel Blackman||CLR EA removed.||CLOSED|
|45||6/6/1900||Michelle Troeltzsch||Remove comment on 4625 that says debug. The HKPFULL is now the default design.||Daniel Blackman||Comment rewritten.||CLOSED|
|48||6/6/1900||Michelle Troeltzsch||The word debug in a comment means that this line of code needs to be revisited. No words debug should exist in the comments when the code is delivered to BATC and GSFC. (See previous AIs on this topic.)||Daniel Blackman||Debug comments or lines removed throughout. Word 'debug' is used in some comments that do not actually indicate debug code. Other debug code is simply commented out, but preserved to demonstrate how some debug function could be performed.||CLOSED|
|53||6/6/1900||Allison Elliot||Comments starting on 4500 of COMMAND.LST are outdated and should be updated.||Daniel Blackman||Comments removed and updated.||CLOSED|
|62||7/27/2000||Michelle Troeltzsch||Assigned to Art:
Figure out how EEPROM will be managed with respect to the DCE FSW Code images. Document this and deliver this to Michelle so she can develop the tools she needs to manage EEPROM.
|Art Rankin||From Art Rankin:
My understanding is that there will be two images provided. The Lower code area image includes the initialization data which can be ignored. It also includes the patchable constant area and lower code area nominally a 16 K area. Both of these areas need to be saved. The Upper code area image includes the initialization data which again can be ignored. The same Patchable constant area and the upper code are nominally the same 2 K for the Patchable constants and the last 16 K for the code. The upper 16 K area should be merged with the lower 16 K for a single image. The problem area comes in due to the Patchable constant area which could be different between these two images during development stages. As such I suggest that we maintain two patchable constant areas one related to each image meaning we need an image area of 34K. It may turn out that with some of the non loadable areas at the beginning of each of these 16K areas would allow reduction of this by a few K.
A load procedure would likely consist of the selected patchable constant area as one transmission followed by the associated code area.
It is not impossible that we will transition to a single image at some time taking advantage of the larger code area. By keeping the 32 K image from a Operational issue it should be a simple transition to change the load to DCE procedure and hopefully minor modifications to the image storage procedure for EEPROM.
From Michelle Troeltzsch:
I spoke with Rob L. on the subject. We agreed to simply our lives and because we have plenty of room, we will just store the complete 32K for each image. Operational you can do the copies from the correct locations.
|64||7/27/2000||Ken Brownsberger||Assigned to Geoff G:
The FUV Detector Command and Telemetry Database has a few errors.
LFDGOTO should only have 1 parameter... not 3 parameters. Drop P2 (Word) and P3 (Word).
LFDPROM should be removed.
LFDTEST should be removed.
LFDPEEK should be removed.
|Geoff Gaines||The UCB C&T Database has been updated accordingly.||CLOSED|
|72||7/28/2000||Ken Brownsberger||Assigned to Geoff G.:
The FUV Detector Subsystem ICD says the DCE Download Packets are zero-filled for download requests smaller than 1024 data bytes. (Section 8.4.4)
This is not true. Remove this sentence.
|Geoff Gaines||The text has been updated in the ICD. This update to the ICD, and a number of other minor updates will be included in the next release (Rev B) of the ICD. This release will be published TBD.||CLOSED|