LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

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
--------------