Introduction
Listed below are the most recent JET-X Command and Data
Handling System software revision notices. They provide a change-tracking
capability, and were driven by non-conformance reports generated during
final delivery testing.
18-Aug-97: V4C-0 CDMS Change Notice
Details
Correction to the row rejection code to reject events, rather than pass events in the row-rejection region. Previously events in the row rejection region were stored even if they would be mapped out due to bad column or pixel tests.
History
The requirement from Panter that row rejection code was implemented was completed for the V4.A roms.
Testing at L.U. of this facility showed that the code was passing all pixels in the row-rejection area, rather than rejecting them.
This was due to exiting the rejection routine at an incorrect point.
18-Aug-97: V4C-1 CDMS Change Notice
Details
Addition of TRM Correctable Error Addresses to the housekeeping for the CP, TP1 and TP2. Previously there was no method to determine the address of a correctable TRM error.
This provides additional diagnostic information to complement the existing TRM uncorrectable error addresses returned for the CP. Providing this additional information as a patch is not possible due to the design of the TRM handling routines.
History
During testing with V4.A at Leicester, a small number of TRM correctable errors were observed on TP1 only. These seemingly only occur at SOT. Diagnostics on the error condition is difficult due to lack of information about the addresses causing the fault.
20-Aug-97: V4C-2 CDMS Change Notice
Details
Provision of an extra word to buffer TEFILREG commands received by the TP from the CP, prior to transmission to the TE, was made. The word in this new buffer is copied to the TE transmit buffer only when the TEFILREG command is processed. This eliminates the contention for the TE transmit buffer between TEFILREG and (H/K or Sequencer) data.
Triggering this race condition would cause the last H/K request command, or last sequencer programming command, to be repeated instead of the TEFILREG command requested.
It should be noted that there is (still) only a single word buffer provided in the TP. This means that a second TEFILREG command could overwrite the buffer before the first is transmitted.
In normal operations, commands are at least 1 second apart. H/K requests to the TE take under a second, so there should be no problem during normal operations.
Loading the sequencers takes at least 1.6 seconds, so it is possible that TEFILREG commands could be lost if they are issued during a TE Sequencer load. Given that this should be protected by the queue stall during the SOT sequence, this condition can only occur is a manual TSET command is followed rapidly by a TEFILREG command. The CDMS Software Manual will be updated to provide information about this.
History
During examination of the TP-TE transmit code, a possible race condition between TEFILREG commands and TE H/K or Sequencer loads was uncovered. given that this race could be triggered by sending TEFILREG commands at any time the TP is requesting TE H/K, a correction was made to avoid this condition.
Notes
A change was made to the polling routine RAM test. The code was changed to test first with 0xFFFF then 0x0000, rather than 0x5555 and 0xAAAA. This allowed optimization of storing 0xFFFF into the ram error address word. This saved enough bytes that the correction to the TE buffer handling was able to fit into the rom.
27-Aug-97: V4C-3 CDMS Change Notice
Details
Update to the CDMS software bad boot handler code to only reset the count after 65536 complete scheduler cycles. Previous code reset the bad boot counter after a single complete pass through the scheduler. This is not optimal, as a number of code paths are not taken on the first pass. Previously, errors in a code path not taken during the first pass would cause a CP soft-reboot loop. This window is now extended to errors in code paths not taken in the first 2 minutes of CP operation after a reboot/normal on.
As part of this change, startup code common to the TP and CP paths was integrated into a subroutine to reduce the size of the CDMS code.
History
Discussion of the bad boot counter with CJE led to the conclusion that a soft-reboot loop of the CP was possible with the current code. This simple modification would reduce this risk significantly.
27-Aug-97: V4C-4 CDMS Change Notice
Details
Addition of code to the CDMS scheduler table is fairly difficult, due to the nature of the returns to the kernel routine which controls this process. A very small stub routine was added which chains the scheduler to the CP health check code. This small stub is easy to replace, without having to move large amounts of code to RAM if additional code needs to be run from the scheduler.
Pre-Patch:
Scheduler JMP
and security check Standard Call/Ret
+-----------+ +--------------+ +-----------------+
| Scheduler |<------------>| Stub Routine |<---------->| CP Health Check |
| (ROM) | | (ROM) | | (ROM) |
+-----------+ +--------------+ +-----------------+
Post-Patch:
Scheduler JMP
and security check Standard Call/Ret
+-----------+ +--------------+ +-----------------+
| Scheduler |<------------>| Stub Routine |<---------->| CP Health Check |
| (ROM) | | plus new code| | (ROM) |
+-----------+ | (RAM) | +-----------------+
+--------------+
History
Discussion of patching the Legri control software highlighted the functionality gained by provision of a 'spare' entry in the Legri scheduler table. This spare entry would be difficult to introduce to the JET-X code at this point in development, but provision of a stub routine is very simple and provides the same functionality.
08-Sep-97: V4C-5 CDMS Change Notice
Details
Update to the TE sequencer loading routine to mimic the code used at Leicester in P4A0-06i.cmd which seems to prevent the TE misconfiguration problem.
The code chage stops the sequencers before loading the TE registers with the new values, and again after loading these values.
The old code did not stop the sequencers prior to loading these registers.
History
TE misconfigurations when moving from FOT->SOT were seen at Panter. Major investigation work at Leicester narrowed the fault down to this condition, though it is not apparent yet why this causes a fault.
10-Sep-97: V4C-6 CDMS Change Notice
Details
The row and column mapping code in the TP's was corrected and compacted. Previously, the node association code did not behave as expected in all cases, and was sub-optimal in size.
History
Examination of the software for code to optimize for space highlighted a flaw with the bad column and pixel node association code, along with a set of major optimizations and byte savings. These bytes will be needed to add TE sequencer ram verification to the onboard software.
15-Sep-97: V4C-7 CDMS Change Notice
Details
When loading the TE sequencer programs, the onboard software loads all 768 bytes with the selected sequencer, and whatever remains in the sequencer buffer. Once loaded, the program counter is reset, and the sequencers are re-read from the TE and compared against the buffer.
A single byte error counter is kept, and is incremented every time there is a mis-match. The counter is shared between the sequencers, and is returned in byte 53 of HK 6 and HK 8.
It is expected that this value is 0 for TE1, and 2 for TE2. If these numbers change, it is envisioned that a software patch to provide additional diagnostic information will be uploaded to characterise the problem further.
History
During testing of the TEs at Leicester to determine the problems when reconfiguring, two faulty ram locations were found in one of the TEs. These locations were not tested prior to this investigation, and it is unknown if the errors are from manufacture or system degredation/handling.
22-Sep-97: V4C-8 CDMS Change Notice
Details
When the TP is processing a frame of data during which the TE ADCs are in self-calibration mode, the TP receives pixels from the TE with zero amplituide.
The TP subtracts the gatti factor from this value, and this causes a bias in the mean calculation of (0 to 255)/16 ADC channels.
This can in turn leads to a burst of buffer overflows when the new hardware threshold level is set, based upon the mean calculation.
This patch checks for negative amplitudes after removing the mean offset, and forces them to 0. Zero amplitude pixels are discarded when calculating the mean, and the hardware threshold means that only the diagnostic region pixels are seen by the TP during an ADC recal.
History
During low gain testing at Panter, and subsequently at Leicester, bursts of buffer overflows, and the associated ramping up of the thresholds was seen in sync with ADC recalibrations.
30-Sep-97: V4C-9 CDMS Change Notice
Details
When the CP recieves events at (0,0), or with the same coordinates as the previous event, the CP encoding routines encode this value as an offset from the previous event of 1 pixel in the X direction.
An oversight in the design of the encoding routines means that the previous X and Y coordinates are reset to (0,0) at the end of each frame and block of data, and not (-1,0). This broke the assumption in the encoding routines that delta-X = delta-Y = 0 was not possible.
This CDMS change adds code to explicitly check for delta-X = delta-Y = 0, and forces these events to be encoded with absolute coordinates.
This change was preferred over the other option of using (-1,0) as the reset condition for the previous coordinates due to the impact such a change would have on the ground system software. Forcing absolute encoding requires no changes to the existing GS software decoders.
History
During testing at Leicester, and previously, misplaced pixels were seen in the diagnostic stripe at 1,0. These were not investigated prior to the sequencer update to correct the invalid markers at the end of lines and end of frames as it was thought possible that these could cause this behaviour.
08-Oct-97: V4C-10 CDMS Change Notice
Details
When the CP receives a 'Transmit Vector Word' request from the BIUS, the 1553 interface specification requirement is as follows:
| Status Word | Data Word | ||
|---|---|---|---|
| SRB | BUSY | Blocks | |
| Data blocks = 0 | * 0 * | 0 | 0 |
| Data blocks > 0 (N) | 1 | 0 | N |
Prior to this change, the actual response was:
| Status Word | Data Word | ||
|---|---|---|---|
| SRB | BUSY | Blocks | |
| Data blocks = 0 | * 1 * | 0 | 0 |
| Data blocks > 0 (N) | 1 | 0 | N |
Given the likely behaviour of BIUS, BIUS would request a block of data from JET-X if the SRB (service request bit) is set. The JET-X response to this, in the case of no data blocks available should be to return a status word with the BUSY bit set, to indicate JET-X cannot process this data.
However, because the SRB was set in the response to the vector word request, JET-X will decrement the vector word from 0 to 0xFFFF, and then proceed to transmit upto 0xFFFF blocks of (useless/random) data to BIUS with SRB=1,BUSY=0, should BIUS continue to request them.
The final block sent will have SRB=0, BUSY=0, and depending on the BIUS programming, SRB=0 may be the only termination condition for data dumping.
After the correction to meet the interface requirements, it becomes impossible for JET-X to transmit junk data by the mechanism above, and the JET-X response to a request for data when none is available is the expected one (SRB=0,BUSY=1).
Notes
- The only way to have a vector word of zero is if 'Transmit Vector Word' is sent when the mass memory is switched off, or if JET-X is not in ground contact mode. Both of these are non-standard conditions.
- Defensive coding in BIUS to check both that SRB=1 and DATA != 0 would also avoid this problem, and it is likely/possible BIUS is coded in this fashion already.
History
During the interface specification review, CHW queried the JET-X behaviour of the BUSY bit, and in discussions between CJE and MPC, this potential problem of handling the SRB was uncovered.
24-Oct-97: V4C-11 CDMS Change Notice
Details
Two sections of code relating to the optical monitor were removed from the CDMS software. The OM has been removed for the flight model.
History
Examination of the 1553 interface code in preparation for the Interface Test hilighted two unnecessary blocks of code.
02-Dec-97: V4C-12 CDMS Change Notice
Details
A small correction to the telemetry generation code to prevent the address of the last corrected TRM address in the CP from being overwritten. A block copy used to generate the HK was 2 bytes longer than required.
History
Testing the new TRM status returns on the flight spare at Birmingham showed the CP address return was not correctly set.
Maintained by Mark CookeLast Updated: 08-Jan-2004