Project

General

Profile

Actions

Bug #483

closed

SY_LFR_S1_BP_P0 = 63.75(s), SY_LFR_S1_BP_P1 = 255(s) make trouble in SBM1/NORMAL

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

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
11/08/2015
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Les 2 parametres SY_LFR_S1_BP_P0 et SY_LFR_S1_BP_P1 peuvent etre positionné à 0xff (255).
Pour SY_LFR_S1_BP_P0, 1 unité = 0,25s et cela donne donc 63.75s.

Le soft de vol l'accepte.
14:49:00.336886, TC_LFR_LOAD_SBM1_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=7, 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_SBM1_PARAMETERS = 25, SOURCE_ID: MISSION_TIMELINE = 110,* SY_LFR_S1_BP_P0 = 63.75(s), SY_LFR_S1_BP_P1 = 255(s)*, CRC = 0x3eb3

14:49:00.339949, 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=29, (PACKET_SEQUENCE_CONTROL=0xc01d), 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=0x800009b8c20f, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000
TM_LFR_PARAMETER_DUMP montre également la prise en compte des valeurs.

Cette configuration induit les dysfonctionnements suivants:
- aucun TM_LFR_SCIENCE_SBM1_BP1_F0 et TM_LFR_SCIENCE_SBM1_BP2_F0 n'est généré.
- les TM_LFR_SCIENCE_NORMAL_BP1_Fi et TM_LFR_SCIENCE_NORMAL_BP2_Fi ne respectent plus leur periodicité (4s et 20s).

TM_LFR_SCIENCE_NORMAL_BP1_Fi
14:49:05.622981, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x800009b9fa3f --> tjs le meme temps
14:49:05.673179, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x800009b9fa42
14:49:57.070464, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x800009b9fb27
14:49:59.623401, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x800009f13a26
14:49:59.663448, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x800009effb0c
14:50:00.763975, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x800009b9fa3f
14:50:52.625093, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x800009f3fb0a
14:50:54.122773, TM_LFR_SCIENCE_NORMAL_BP1_F1, TIME=0x800009f3fa24
14:50:55.929873, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x800009b9fa3f

TM_LFR_SCIENCE_NORMAL_BP2_Fi
14:51:50.631635, TM_LFR_SCIENCE_NORMAL_BP2_F2, TIME=0x80000a5efad0
14:52:45.128414, TM_LFR_SCIENCE_NORMAL_BP2_F1, TIME=0x80000a61f9e9
14:52:48.351597, TM_LFR_SCIENCE_NORMAL_BP2_F0, TIME=0x800009b9fa3f
14:55:33.629441, TM_LFR_SCIENCE_NORMAL_BP2_F2, TIME=0x80000b0bfa7c
14:56:30.627825, TM_LFR_SCIENCE_NORMAL_BP2_F1, TIME=0x80000b43797d
14:57:29.594008, TM_LFR_SCIENCE_NORMAL_BP2_F0, TIME=0x800009b9fa3f
14:58:25.664264, TM_LFR_SCIENCE_NORMAL_BP2_F2, TIME=0x80000be9fa10
15:00:16.626657, TM_LFR_SCIENCE_NORMAL_BP2_F1, TIME=0x80000c25790c

Le fichier de log (2015_08_11-15_16_59-Detail.txt) se trouve dans /home/validation/data/R3/3.0.0.8/1.1.88/SVS-0031.

Le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0031/sbm1_mode_parameter_set.py.

Ce fonctionnement étant loin d'etre utilisé,
- soit on trouve le bug (un ecrasement de memoire)
- soit dans l'ICD on met à jour le domaine de définition pour eliminer le pb.

Contexte du test
----------------
FSW 3.0.0.8
VHDL 1.1.88
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

Actions

Also available in: Atom PDF