Project

General

Profile

Bug #1084

PA_RPW_BYTE_POSITION wrong into a TM_LFR_TC_EXE_INCONSISTENT on TC_LFR_LOAD_KCOEFFICIENTS

Added by Veronique bouzid over 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
25/04/2017
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Cela ressemble à un bug deja tracé (#426)
Sur TC_LFR_LOAD_KCOEFFICIENTS, un seul champ genere une TM_LFR_TC_EXE_INCONSISTENT, c est KCOEFF_FREQ.
Envoi du champ KCOEFF_FREQ = 36 pour generer l inconsistent

08:31:25.474498, TC_LFR_LOAD_KCOEFFICIENTS, 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=7906, (PACKET_SEQUENCE_CONTROL=0xdee2), PACKET_LENGTH=135, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_KCOEFFICIENTS = 93, SOURCE_ID: MISSION_TIMELINE = 110, KCOEFF_FREQ = 36, KCOEFF_1 = 1065353216, KCOEFF_2 = 1065353216, KCOEFF_3 = 1065353216, KCOEFF_4 = 1065353216, KCOEFF_5 = 1065353216, KCOEFF_6 = 1065353216, KCOEFF_7 = 1065353216, KCOEFF_8 = 1065353216, KCOEFF_9 = 1065353216, KCOEFF_10 = 1065353216, KCOEFF_11 = 1065353216, KCOEFF_12 = 1065353216, KCOEFF_13 = 1065353216, KCOEFF_14 = 1065353216, KCOEFF_15 = 1065353216, KCOEFF_16 = 1065353216, KCOEFF_17 = 1065353216, KCOEFF_18 = 1065353216, KCOEFF_19 = 1065353216, KCOEFF_20 = 1065353216, KCOEFF_21 = 1065353216, KCOEFF_22 = 1065353216, KCOEFF_23 = 1065353216, KCOEFF_24 = 1065353216, KCOEFF_25 = 1065353216, KCOEFF_26 = 1065353216, KCOEFF_27 = 1065353216, KCOEFF_28 = 1065353216, KCOEFF_29 = 1065353216, KCOEFF_30 = 1065353216, KCOEFF_31 = 1065353216, KCOEFF_32 = 1065353216,CRC = 0x436f

08:31:25.484079, TM_LFR_TC_EXE_INCONSISTENT, 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=89, (PACKET_SEQUENCE_CONTROL=0xc059), PACKET_LENGTH=19, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001fd995, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xdee2, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=93, PA_RPW_BYTE_POSITION=11, PA_RPW_RCV_VALUE=36

On devrait avoir PA_RPW_BYTE_POSITION = 10 et non 11

J ai vérifié les autres commande de type LOAD_xxx_PAR. On met toujours le BYTE position du parametre et la valeur est l octet LSB du champ.

Paul, peux-tu verifier cela?

Le script utilisé est /opt/VALIDATION_R3plusplus/lfrverif/LFR_SVS/SVS-0008/tc_execution_failure_report.py.
Les fichiers de log (2017_04_20-08_32_02*) sont rangés dans /home/validation/data/R3++/3.2.0.15/3.1.91/SVS-0008

Contexte du test
---------------------
FSW 3.2.0.15
VHDL 3.1.91
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+
EQM sans Timegen
StarDundee
--------------


Related issues

Related to Bug #426: R3 *** TC_LFR_LOAD_KCOEFFICIENTS: SY_LFR_KCOEFF_FREQUENCY ne doit pas etre superieur à 35Closed2015-06-05

History

#1 Updated by Veronique bouzid over 4 years ago

  • Related to Bug #426: R3 *** TC_LFR_LOAD_KCOEFFICIENTS: SY_LFR_KCOEFF_FREQUENCY ne doit pas etre superieur à 35 added

#2 Updated by paul leroy over 4 years ago

  • Assignee changed from paul leroy to Veronique bouzid

Je confirme, j'ai mis la position du LSB alors qu'il faudrait mettre la position du MSB, la règle étant celle que tu dis, à savoir qu'on indique la position du champ et on met comme valeur le LSB du champ. Correction à venir pour fsw >= 3.2.0.16!

#3 Updated by bruno katra about 4 years ago

Ce comportement non nominal est décrit dans le SUM 1.5 la demande du CNES.
Correction a valider puis cloturer l'issue QUAND LE SUM AURA ETE MIS A JOUR !

#4 Updated by Veronique bouzid about 3 years ago

  • Status changed from New to Closed

Bug corrigé en 3.2.0.18 ( version HK annoncé en 3.2.0.17)

08:45:53.834152, TC_LFR_LOAD_KCOEFFICIENTS, 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=3521, (PACKET_SEQUENCE_CONTROL=0xcdc1), PACKET_LENGTH=135, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_KCOEFFICIENTS = 93, SOURCE_ID: MISSION_TIMELINE = 110, KCOEFF_FREQ = 36, KCOEFF_1 = 1065353216, KCOEFF_2 = 1065353216, KCOEFF_3 = 1065353216, KCOEFF_4 = 1065353216, KCOEFF_5 = 1065353216, KCOEFF_6 = 1065353216, KCOEFF_7 = 1065353216, KCOEFF_8 = 1065353216, KCOEFF_9 = 1065353216, KCOEFF_10 = 1065353216, KCOEFF_11 = 1065353216, KCOEFF_12 = 1065353216, KCOEFF_13 = 1065353216, KCOEFF_14 = 1065353216, KCOEFF_15 = 1065353216, KCOEFF_16 = 1065353216, KCOEFF_17 = 1065353216, KCOEFF_18 = 1065353216, KCOEFF_19 = 1065353216, KCOEFF_20 = 1065353216, KCOEFF_21 = 1065353216, KCOEFF_22 = 1065353216, KCOEFF_23 = 1065353216, KCOEFF_24 = 1065353216, KCOEFF_25 = 1065353216, KCOEFF_26 = 1065353216, KCOEFF_27 = 1065353216, KCOEFF_28 = 1065353216, KCOEFF_29 = 1065353216, KCOEFF_30 = 1065353216, KCOEFF_31 = 1065353216, KCOEFF_32 = 1065353216,CRC = 0x8600

08:45:53.844346, TM_LFR_TC_EXE_INCONSISTENT, 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=87, (PACKET_SEQUENCE_CONTROL=0xc057), PACKET_LENGTH=19, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x800000188465, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xcdc1, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=93, PA_RPW_BYTE_POSITION=10, PA_RPW_RCV_VALUE=36

Les fichiers (2018_07_12-08_45_59*) se trouvent dans /home/validation/data/R3++/3.2.0.18/1.1.91/SVS-0008.

Contexte du test
----------------
FSW 3.2.0.18
VHDL 1.1.91
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+
EM1 sans Timegen
StarDundee

#5 Updated by Veronique bouzid about 3 years ago

  • Assignee changed from Veronique bouzid to bruno katra

Attention remettre à jour le SUM version 1.5 puisque le bug est corrigé:

Ce comportement non nominal est décrit dans le SUM 1.5 la demande du CNES.
Correction a valider puis cloturer l'issue QUAND LE SUM AURA ETE MIS A JOUR !

#6 Updated by bruno katra about 3 years ago

  • Status changed from Closed to In Progress

#7 Updated by Veronique bouzid almost 3 years ago

  • Status changed from In Progress to Closed

#8 Updated by bruno katra almost 3 years ago

SUM 1.6 mis à jour suite à correction du bug

Also available in: Atom PDF