|1||6/5/1900||Rob Lampereur||Create a linkage in the code between the Design Document and the 8051 assembly code. To make the logic flow easier to map between the design document and and code itself.
Create labels within the code, which we reference within the document.
|This will be implemented, but in a gradual fashion - with completion planned for when code goes to Level 3.||OPEN|
|2||6/5/1900||Rob Lampereur||Describe the Rational behind the Main Loop order, and that it is arbitrary. Basically, add into your comments that these are event driven activities - so the order is arbitrary.||Comment added to MAINROUTINE comment block||CLOSED|
|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.||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.
|Comment added to BACKGROUND comment block||CLOSED|
|5||6/5/1900||Chris Dorato||For every subroutine in the code, there should be a summary block describing what the subroutine is and what it does, what the inputs and outputs are, and what the revision history is - starting from this point in time onward.||Comment blocks added to every subroutine, some macro definitions, and main loop. To properly fill-in each comment block will take some time, but I will revise comment blocks as development continues...||OPEN|
|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.||'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.
|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.
|The list has been started in the commands.inc file, which is read by all source files.||CLOSED|
|9||6/5/1900||Michelle Troeltzsch||Put comments in table definitions within the Patchable constants file.||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.||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.
|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|
|12||6/5/1900||Art Rankin||For the section of FSW that reads and populates the PH data buffers, look at the BOOT/OPERATE flag - and if in BOOT, do NOT read the PH data and do NOT overwrite the buffer area.||This will be implemented, but has not been added to the code yet. (As of 7/14/2000.)||OPEN|
|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.||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|
|14||6/5/1900||Ken Brownsberger||If a properly formatted command is sent, but it does not exist in the OPCODE list, then report a diagnostic and an HST error. (Daniel is recommending Diagnostic 11 - command opcode not implemented.)||Separate COS and GALEX command tables have been implemented to support this AI.||CLOSED|
|15||6/5/1900||Daniel Blackman||SPARE commands currently in the command jump table should be replaced with room for future implementation of TBD commands. For now, they should be basically function as a NOOP - but, also report an illegal command diagnostic. (See previous AI).||Done||CLOSED|
|16||6/5/1900||Art Rankin||Confirm that a HSK packet is returned as a result of the JMP command. i.e., if we jump from BOOT to OPERATE, we get a HSK packet - without having to send another follow-up command, like a NOOP.||This will be implemented, but has not been as of 7/14/2000.||OPEN|
|17||6/5/1900||Rob Lampereur||Add functionality to make the Test Commands only usable if a TEST ENABLE command (a new command) has been sent. The default is that Test Commands are DISABLED. Also, when dropping to BOOT, Test Commands should be DISABLED.||Test commands will be included in code only by a non-flight compiler directive. Thus, no test commands will be included in the FSW burned into PROM or in the FSW loaded into RAM for on-orbit operations. FSW with test commands would only be loaded during early, ground test and debug situations. See AI #7.||OPEN|
|18||6/5/1900||Daniel Blackman||Update comment in UPDATE_CTRS in EXECUTIV.LST. The Comment, 'Timer??? I think...' is not descriptive enough.||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.
|20||6/5/1900||Rob Lampereur||Set the High-water mark to just below MAX in the PROM, but copy it over to the patchable constants area, and use this value for your CHECK_STACK code. This way, you can patch it to a low value to verify that the DIAGNOSTIC 7 function is working properly.
Also, add a TLM item for the stack max, so that this can be bundled with DIAG 7 for use with an HST error.
|Ability to set High-water Mark via patchable constant will be tested for viability. If functions properly, with no adverse side effects - will implement, and will use patchable constant value to bundle with DIAG 7 for HST error of this type.||OPEN|
|21||6/5/1900||Will Clement||Revise the format of the Jump Table. See code on floppy disk and hardcopy from Will C.||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|
|22||6/6/1900||Michelle Troeltzsch||Add more text to the interrupt comments (starting at line 2252 of INITIALZ.LST). Explain what the interrupt does. If need additional space, put in on the line above.
|23||6/6/1900||Michelle Troeltzsch||Scrub all bug and debug comments throughout the entire code package. If a problem that your tracking with these kinds of comments still exists at the time the code is ready to go to Level 2 CM, then the problem needs to be tracked officially and paperwork generated.
Also, dont leave dangling comments about bugs and possible fixes. If the bug was fixed, update the comment and say it was fixed.
|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|
|24||6/6/1900||Art Rankin||Generate a lien list of bugs or problems that exist in the code when it is brought to Level 2. Maintain that list and update it appropriately so that it can be reviewed at the time the code is brought to Level 3. (Level 3 = Delivery to BATC.)||This will be done when code goes from Level 1 to Level 2, and will be part of the delivery package when code goes to Level 3. As of 7/14/2000, code is at Level 1 - so no formal, project-wide lien list exists yet.||OPEN|
|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.||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|
|26||6/6/1900||Ken Brownsberger||Remove the functionality at line 3389 of INITIALZ.LST. Do NOT perform the NOTSAFE. We will ALWAYS shut off HV, Door, etc...||The XSPEC assembly control shows the old code and the new code. I want to document how I would have designed to code to be tolerant of some kinds of errors, because I believe it to be a better, safer design for general use. However, I will acquiesce to the review board and leave XSPEC turned off for flight code and qual testing. XSPEC will be turned on for use in the lab during detector development. Warning: leaving these features out of the boot PROM removes any possibility of allowing the detector to continue transmitting science data after a reset, even a spurious reset caused by SEU.||OPEN|
|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.
|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.
|Comments added as requested.
Also, comments added in COMMON.INC
|29||6/6/1900||Rob Lampereur||Lines 4378 of COMMANDS.LST
Fix the code if the lock bits are corrected in hardware. Do not unlock the Protected Control Register, unless you need it.
If hardware is not corrected, document WHY you are doing what you are doing
See also AI 46
|The purpose of the lockbit is to prevent inadvertant hardware operation of critical items with a COPY or UPLOAD command. As it turns out, the Control Register that has the lock-bit contains the Actuator Enable, Actuator ON and Door Limit Switch Override commands, which are exactly the hardware operations that should only be used in emergency situations - and thus, would benefit with this added layer of security.
All commands that go through the Control Registers (both protected and unprotected), by default, unlock and then relock the register - which simplifies the FSW design, and maintains the safety for which the lock-bit was implemented.
Resolution of this AI is to update the DCE SDD to match the hardware design, and the FSW design.
See UCB PFR#0004 documents the wiring of the Control Registers.
|30||6/6/1900||Daniel Blackman||Line 4385, COMMANDS.LST
Strike comment about I wonder if we should do this.
|Comments struck. The sentiment remains.||CLOSED|
|31||6/6/1900||Rob Lampereur||Lines 2584 and on, in INITIALZ.LST
Add comments in FINDRESETTYPE, which indicate what kind of reset took place - and why.
|32||6/6/1900||Michelle Troeltzsch||Change text of Record this dreadful event, to something along the lines of issue a DCE diagnostic, and - if appropriate - Report an HST error.||Replaced the word 'dreadful' with 'diagnostic'. This is a macro that does a general purpose function. Appropriate comments are near the macro call describe the nature of the diagnostic.||CLOSED|
|33||6/6/1900||Allison Elliot||The Watchdog should be disabled after ALL resets, not just a POR.||Acquiescence. See Item 26.||CLOSED|
|34||6/6/1900||Ken Brownsberger||Assigned to: Ken B.
Update DCE-Reset diagram to include the 255 POR check.
|SDD still needs to be updated.||OPEN|
|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.
|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 ***
|36||6/6/1900||Ken Brownsberger||Flight CODE should not decide what flight hardware were running on because of hardware talkbacks, and then set behavior for future operations because of this determination.
The SETPROJECT, at line 4184, functionality should NOT test the RXD1 line and determine whether or not the DCE is COS or GALEX.
A suggestion was made to use conditional compiles to generate code sets that are unique to the different PROJECTS, and different lab hardware environments. This is to remove the possibility of executing the wrong code set for COS on the flight hardware. (Either during test - or worse - on orbit.)
|Implemented as per item 26.||CLOSED|
|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.
|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.)
|Removed CHECKBREADBOARD from code||CLOSED|
|39||6/6/1900||Rob Lampereur||Line 3204, (CLRSOMEBITS) in INITIALZ.LST.
Document which bits youre clearing and why theyre being cleared.
|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)||Done||CLOSED|
|41||6/6/1900||Ken Brownsberger||Assigned to Ken B:
Change 12 seconds to 10 seconds in Figure 4.2-1 of SDD.
Remove background calculations in 126.96.36.199.1 of SDD.
Remove the Start CRC calculations in 188.8.131.52.2, in the minimal initialization sequence. (Change to Setup or Initialize for CRC calculations.)
|SDD needs to be updated.||OPEN|
|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.||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.||CLR EA removed.||CLOSED|
|44||6/6/1900||Michelle Troeltzsch||Try to scrub any and all comments in code that are no longer valid - especially those comments that are invalid because the code the comment was referring has been removed.||At least some comments of this sort have been removed from code. Further updates to continue as code is finalized.||OPEN|
|45||6/6/1900||Michelle Troeltzsch||Remove comment on 4625 that says debug. The HKPFULL is now the default design.||Comment rewritten.||CLOSED|
|46||6/6/1900||Ken Brownsberger||Assigned to Ken B.:
Is the protected control register wired incorrectly for the DCE? If so, when is this going to be fixed?
Controls 1 should have been locked.
Controls 2 currently has the lock.
Consult with John Andrews, Barry Welsh, and electrical engineers working at UCB.
Daniel currently implements an undesirable workaround because of this problem. Make certain that he only does this if it the hardware is NOT going to be fixed. If the hardware does not get fixed - and the wrong controls register is stuck with the lock... then consider unlocking it initially, and keeping it unlocked indefinitely.
|See Response for AI#29||OPEN|
|47||6/6/1900||Ken Brownsberger||Assigned to Ken B.:
Is there a problem in the Actel for the PROM enable? Does UCB have a problem with the PROM that has not been documented, and that Daniel has created code to fix?
|See UCB ECO#0028. Currently, PROM enable command causes DCE to hang. Hardware fix will either involve an ACTEL change or a board-level change.
In any event, PROM enable functionality (i.e., memory bank switching) is being dropped from the DCE - so the DCE FSW will not support this capability, and the FSW will be changed accordingly to drop these features.
|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.)||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|
|49||6/6/1900||Allison Elliot||Add a banner comment to the command traffic ISRs on 2307 of INTERNAL.LST. (See previous AI on this topic)||Subroutine banners added, to be filled-in during development||OPEN|
|50||6/6/1900||Ken Brownsberger||Assigned to Ken B.
Get the COMMON.INC file and scrub it with the existing DCE HW/SW Interface Document. Provide any inputs/updates to Rich B.
|Open. Due to personnel changes, we are in the process of finding a new author for the DCE HW/SW Interface Document||OPEN|
|51||6/6/1900||Art Rankin||Add a counter to the Command Traffic ISR, so that we can keep track of how many Command words are rejected by the CHECKRXD routine. (Line 2417 of INTERNAL.LST)||Not yet implemented as of 7/14/2000. Will be a variable that we can place a memory monitor on to inspect value.||OPEN|
|52||6/6/1900||Ken Brownsberger||Assigned to Ken B.:
Work with Daniel to fix Logic Flow of Timer Tick ISR in SDD. Current flow diagram does not match 8051 code.
|SDD needs to be updated.||OPEN|
|53||6/6/1900||Allison Elliot||Comments starting on 4500 of COMMAND.LST are outdated and should be updated.||Comments removed and updated.||CLOSED|
|54||6/6/1900||Allison Elliot||There needs to be logic at line 4489 of COMMAND.LST, so that the
SETB F0 is not set when the CRC parameter is not set to zero.