Project

General

Profile

Actions

Bug #912

closed

champ HK_LFR_SC_POTENTIEL_FLAG passe à OFF

Added by Veronique bouzid over 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
18/01/2017
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Le script utilisé est /home/validation/SCRIPT/R3+/set_load_filter_par.py.

Normalement le champ HK_LFR_SC_POTENTIEL_FLAG est positionné à ON apres la sequence de boot. Je verifie donc que cette valeur nominale
ne change pas.
Dans ce test, j observe que le flag passe à OFF.
ici les traces de la sequence

09:00:32.563373, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=16, (PACKET_SEQUENCE_CONTROL=0xc010), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x80000012222c, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: ERROR_WAIT = 1, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,

09:00:32.889086, TC_LFR_LOAD_FILTER_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=21, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_FILTER_PAR = 97, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0x0, DOE_SPARE=0x0, SY_LFR_PAS_FILTER_ENABLED: DISABLED = 0, SY_LFR_PAS_FILTER_MODULUS=4, SY_LFR_PAS_FILTER_TBAD=1065353216, SY_LFR_PAS_FILTER_OFFSET=0, SY_LFR_PAS_FILTER_SHIFT=1056964608, SY_LFR_PAS_FILTER_DELTA_F=1020054733, CRC = 0xf136

09:00:32.899891, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=5, (PACKET_SEQUENCE_CONTROL=0xc005), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x80000012782f, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000

09:00:33.563494, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=17, (PACKET_SEQUENCE_CONTROL=0xc011), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x80000013222c, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: ERROR_WAIT = 1, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: OFF = 0, HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,

C'est le seul test pour l instant ou j ai observé ce phénomeme. Dans ce test on envoie 2 TC_LOAD_FILTER_PAR , la première n induit pas le changement du champ
HK_LFR_SC_POTENTIEL_FLAG mais la deuxieme OUI.

Les fichiers (2017_01_18-09_00_41*) sont rangés dans le repertoire /home/validation/data/R3+/3.1.0.6/3.1.91/TESTS-UNITAIRES/set_load_filter.

--> IL faut revoir le traitement de cette TC (voir #911)

Contexte du test
----------------
FSW 3.1.0.6
VHDL 3.1.91
PFM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+
StarDundee

Actions #1

Updated by Veronique bouzid over 7 years ago

  • Description updated (diff)
Actions #2

Updated by paul leroy over 7 years ago

  • Assignee changed from paul leroy to Veronique bouzid

J'ai trouvé le bug, il s'agissait d'une erreur de masque dans la fonction suivante, qui écrasait le bit sc_potential_flag

void set_sy_lfr_pas_filter_enabled( bool state )

Je corrige pour fsw >= 3.1.0.7

Actions #3

Updated by Veronique bouzid about 7 years ago

  • Status changed from New to Closed

Bug corrigé en 3.1.0.7.
Le champ HK_LFR_SC_POTENTIEL_FLAG: reste bien positionné à 1.

Le script utilisé est /home/validation/SCRIPT/R3+/send_load_filter_par.py.
Les fichiers de log ( 2017_02_03-10_48_06-*) sont rangés dans le répertoire /home/validation/data/R3+/3.1.0.7/1.1.91/TESTS-UNITAIRES/set_load_filter.

Contexte du test
----------------
FSW 3.1.0.7
VHDL 1.1.91
EM1 sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+
StarDundee

Actions

Also available in: Atom PDF