Problem/Failure Report
THM_PFR_809
PFR-809
Title: Compression Errors in Huffman
Assembly : IDPU
Component : CMP Module
Originator: Peter Harvey
Organization: SSL
Phone: 510-642-0643
Problem Occurred During (Check one )
SubAssembly : FSW
Units Affected:
Units fixed:
O O O O O x
-
Date: May 25, 2007
Email :prh@ssl.berkeley.edu
□ Functional test □ Qualification test □ S/C Integration □ Launch operations  Flight
Environment when failure occurred:
□ Ambient
□ Vibration
□ Shock
□ Acoustic
□ Thermal
□ Vacuum
□ Thermal-Vacuum
□ EMI/EMC
Problem Description
(In this section it is important to document the specific symptoms of the problem. In the event we see it happen
again, we would like to know as much as possible.)
I've completed my analysis of the raw and compressed data from the recent probe D compression test. Here is a
summary of: apid, number of compressed packets tested, test status, compression algorithm, and compression ratio.
445 432 OK delta-mod 2.8
447 218 OK delta-mod 2.6
448 216 OK delta-mod 1.5
449 4088 OK delta-mod 4.3
44b 2048 OK delta-mod 4.2
44c 1785 OK delta-mod 2.3
44d 108 OK Huffman 1.4
44e 16 OK Huffman 1.4
456 288 BAD Huffman 2.1 (2 bad packets)
459 287 BAD Huffman 1.4 (34 bad packets)
45f 95 OK Huffman 3.4
461 217 OK delta-mod 1.2
About 4.5 percent of the Huffman-compressed packets had problems: in each case, the ground compression
algorithm produced a different output than the IDPU compression, and the result of decompressing the IDPUcompressed packet did not match the original raw packet.
There seem to be at least two different things going on with the Huffman compressed data. Some packets had big
chunks that differed (e.g. packets 1050,1051 from apid 456, packet 2220 from apid 459). Others differed only at the
very end of the packet where the decompression keys are stored (e.g. packet 1015 and many others from apid 459).
Some packets displayed both symptoms (e.g. packet 1018 from apid 459).
Analyses Performed to Determine Cause
(How do we know how the failure happened? Was it a bad part, bad handling, what? )
Using the Huffman simulator, all packets that differed from the simulation were the correct size, yet the
data in some blocks was different than the simulators got. The keys for these blocks indicated the data
should be “RAW” data, as the length code was the same as the raw length. For example, the code “00”
used for a length of 256 bytes.
106731213
2/13/2016
Page 1 of 3
Problem/Failure Report
THM_PFR_809
Using the simulator, it was determined that the blocks that differed from the ground simulations were
actually the EXACT length of the RAW. Namely, the compressed and the RAW versions were the same
length of 256 bytes.
The CMP module should use RAW encoding when the RAW is less than or equal to the compressed
version. Thus, the code that decided to use “RAW” encoding was triggerring on “<” but not the “=” part.
Corrective Action/ Resolution
(How do we fix the unit? And how do we make sure it doesn't happen again?)
The “DSB” opcode does not produce a carry when the operands (HL and BC) are equal. Registers BC
were needed following the comparison, but HL were not. So, the patch was to decrease the value in HL
by 1 and perform the comparison. To do this, the unused Restart 5 was used to insert a 3-byte routine
“BKGRST5” which decrements HL , performs the subtraction DSB and returns.
Version 4.2 CMP module H4_BLOCK routine (Red shows the areas that need to change )
444 024D:
445 024D:
446 024D:
447 024D:
448 024D:
449 024D:
450 024D:
451 0250:
452 0253:
453 0253:
454 0254:
455 0255:
456 0258:
457 0259:
CD 0285r
22 6E80
44
4D
2A 6E8A
08
DA 02AEr
;=====================================================================
; HUFFMAN 4-BIT BLOCK
; ON ENTRY: INPTR->INPUT BLOCK OF BLKSIZE, OUTPTR->WHERE TO STORE RESULT
; ON EXIT: OUTPTR->WHERE WE STOPPED
;=====================================================================
H4_BLOCK:
CALL
H4_GETLENG
;[DE]=BITS, [HL]=BYTE LENGTH OF RESULT
SHLD
CMPSIZE
;SAVE COMPRESSED SIZE
;
MOV
B,H
;IF RAW BLKSIZE < COMPRESSED SIZE
MOV
C,L
; THEN WE'D RATHER USE RAW DATA
LHLD
BLKSIZE
;
DSB
.
;
JC
H4_RAW
;
H4_BLOCK patch replacing DSB with Restart 5 opcode (Blue)
444 024D:
445 024D:
446 024D:
447 024D:
448 024D:
449 024D:
450 024D:
451 0250:
452 0253:
453 0253:
454 0254:
455 0255:
456 0258:
457 0259:
CD 0285r
22 6E80
44
4D
2A 6E8A
EF
DA 02AEr
;=====================================================================
; HUFFMAN 4-BIT BLOCK
; ON ENTRY: INPTR->INPUT BLOCK OF BLKSIZE, OUTPTR->WHERE TO STORE RESULT
; ON EXIT: OUTPTR->WHERE WE STOPPED
;=====================================================================
H4_BLOCK:
CALL
H4_GETLENG
;[DE]=BITS, [HL]=BYTE LENGTH OF RESULT
SHLD
CMPSIZE
;SAVE COMPRESSED SIZE
;
MOV
B,H
;IF RAW BLKSIZE < COMPRESSED SIZE
MOV
C,L
; THEN WE'D RATHER USE RAW DATA
LHLD
BLKSIZE
;
RST
5
;
JC
H4_RAW
;
BKGRST5 patch Adding “LE” function at Restart 5 (Blue)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
0000:
0000:
0000:
0000:
0000:
0000:
0000:
0000:
0000:
0000:
0025:
0026:
0028:
0028:
0029:
002A:
4D
0028
2B
08
C9
;====================================================================
; THEMIS FLIGHT PROGRAM - BACKGROUND FUNCTION LESS THAN OR EQUAL ISSUE
; WRITTEN BY PETER R HARVEY
; FILE: BKGRST5.A
; REVA: 5/29/07 PRH
;
;====================================================================
LOCZ
EQU
0028H
;THIS IS THE PATCH LOCATION
;
ORG
LOCZ-3
;TELL LOADER IT IS
DB
'M'
;IN THE MAIN COMPUTER AREA
DW
LOCZ
;AT THIS LOCATION
;
RST5
DCX
H
;SET CARRY IF [HL] IS LE [BC]
DSB
.
;
RET
.
The patch was tested on the ETU compressing one of the 456 packets that had this problem. The patch
version was identified as Version 4.5.
Acceptance:
106731213
2/13/2016
Page 2 of 3
Problem/Failure Report
THM_PFR_809
FSW: Peter Harvey__________________________Date:____________;
ISE: Michael Ludlam________________________ Date:____________;
106731213
2/13/2016
Page 3 of 3