Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012017-03-10T13:24:12ZRedmine
Redmine LFR-FSW - Bug #966 (Closed): Comment valider le SSS-CP-EQS-526https://hephaistos.lpp.polytechnique.fr/redmine/issues/9662017-03-10T13:24:12ZVeronique bouzid
<p>Thomas propose d injecter sur V_F3, E1_F3, E2_F3<br />- un signal sinusoidal à 0.1hz<br />- un signal carré à 0.1hz<br />- un signal sinusoidal à 10hz</p>
<p>Les tests ont été effectués sur pc-solar1 par Bruno en utilisant le LFR-GSE et le logiciel de generation des signaux<br />Pour cela on a utilisé une ANALOG DISCOVERY avec une pin connecté à V_f3 et dans un deuxieme temps 2 pins connectées sur E1_F3 et E2_F3.<br />Le logiciel de generation des signaux ne sait piloter que 2 signaux max.</p>
<p>Les résultats sont actuellement sur pc-solar3 dans le répertoire /home/validation/data/R3++/3.2.0.2/1.1.91/SC_potential_mean_HK_datasets.<br />Les fichiers générés sont<br />Sine_0.1Hz_on_E1E2_packet_log.data<br />Sine_0.1Hz_on_E1E2_packet_record.data<br />Sine_0.1Hz_on_V_packet_log.data<br />Sine_0.1Hz_on_V_packet_record.data<br />Sine_10Hz_on_E1E2_packet_log.data<br />Sine_10Hz_on_E1E2_packet_record.data<br />Sine_10Hz_on_V_packet_log.data<br />Sine_10Hz_on_V_packet_record.data<br />Square_0.1Hz_on_E1E2_packet_log.data<br />Square_0.1Hz_on_E1E2_packet_record.data<br />Square_0.1Hz_on_V_packet_log.data<br />Square_0.1Hz_on_V_packet_record.data</p>
<p>la decom R3++ de Bruno a été copiée dans le répertoire /home/validation/bin. Elle se nomme LFR_packet_decom-linux-x86_64<br />[validation@pc-solar3 bin]$ LFR_packet_decom-linux-x86_64</p>
*<strong><b></strong>*</b>**<strong>**</strong>*************************************<br />LFR instrument decommutation program version 0r107<br />ONLY COMPATIBLE WITH FSW 3.2.x DATADUMP (R3++)
<hr />
<p>Usage: LFR_packet_decom-linux-x86_64 [LFR L1 binary packets file]</p> LFR-FSW - Bug #912 (Closed): champ HK_LFR_SC_POTENTIEL_FLAG passe à OFFhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9122017-01-18T10:28:12ZVeronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3+/set_load_filter_par.py.</p>
<p>Normalement le champ HK_LFR_SC_POTENTIEL_FLAG est positionné à ON apres la sequence de boot. Je verifie donc que cette valeur nominale<br />ne change pas.<br />Dans ce test, j observe que le flag passe à OFF.<br />ici les traces de la sequence</p>
<p>09:00:32.563373, <strong>TM_LFR_HK</strong>, 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, <strong>HK_LFR_SC_POTENTIEL_FLAG: ON = 1,</strong> HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,</p>
<p>09:00:32.889086, <strong>TC_LFR_LOAD_FILTER_PAR</strong>, 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</p>
<p>09:00:32.899891, <strong>TM_LFR_TC_EXE_SUCCESS</strong>, 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</p>
<p>09:00:33.563494, <strong>TM_LFR_HK</strong>, 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, <strong>HK_LFR_SC_POTENTIEL_FLAG: OFF = 0</strong>, HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,</p>
<p>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<br />HK_LFR_SC_POTENTIEL_FLAG mais la deuxieme OUI.</p>
<p>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.</p>
<p>--> IL faut revoir le traitement de cette TC (voir <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: champ HK_LFR_PAS_FILTER_ENABLED non mis à jour apres envoi TC_LFR_LOAD_FILTER_PAR (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/911">#911</a>)</p>
<p>Contexte du test<br />----------------<br />FSW 3.1.0.6<br />VHDL 3.1.91<br />PFM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #911 (Closed): champ HK_LFR_PAS_FILTER_ENABLED non mis à jour apres envoi TC_LFR_LO...https://hephaistos.lpp.polytechnique.fr/redmine/issues/9112017-01-18T10:14:24ZVeronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3+/set_load_filter_par.py.<br />Le scénario est le suivant<br />Pas d'envoi de TC_LFR_LOAD_FILTER_PAR<br />--> le champ HK_LFR_PAS_FILTER_ENABLED est bien initialisé à DISABLED (meme si ce n est pas la valeur par défaut déclarée dans ICD 4.1 et 4.3)</p>
<p>09:00:25.563361, <strong>TM_LFR_HK,</strong> 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=9, (PACKET_SEQUENCE_CONTROL=0xc009), 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=0x8000000b222c, 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
*</p>
<p>Envoi de la TC_LFR_LOAD_FILTER_PAR avec SY_LFR_PAS_FILTER_ENABLED: ENABLED = 1</p>
<p>09:00:23.866993, <strong>TC_LFR_LOAD_FILTER_PAR,</strong> 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, <strong>SY_LFR_PAS_FILTER_ENABLED: ENABLED = 1</strong>, 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 = 0x5fca</p>
<p>09:00:24.563394, <strong>TM_LFR_HK</strong>, 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=8, (PACKET_SEQUENCE_CONTROL=0xc008), 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=0x8000000a222c, 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, <strong>HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,</strong><br />et<br />09:00:25.563361, <strong>TM_LFR_HK</strong>, 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=9, (PACKET_SEQUENCE_CONTROL=0xc009), 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=0x8000000b222c, 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, <strong>HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0</strong></p>
<p>--> Le champ n est jamais mis à jour.</p>
<p>Les fichiers (2017_01_18-09_00_41*) sont rangés dans le répertoire /home/validation/data/R3+/3.1.0.6/3.1.91/TESTS-UNITAIRES/set_load_filter.</p>
<p>Contexte du test<br />----------------<br />FSW 3.1.0.6<br />VHDL 3.1.91<br />PFM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #869 (Closed): champ SY_LFR_PAS_FILTER_DELTA_F de TM_LFR_PARAMETER_PAR non initiali...https://hephaistos.lpp.polytechnique.fr/redmine/issues/8692016-12-29T14:37:33ZVeronique bouzid
<p>En jouant le script /home/validation/SCRIPT/R3+/send_one_update_info.py, on envoie la séquence suivante<br />TC_LFR_UPDATE_INFO<br />TC_LFR_DUMP_PAR<br />TM_LFR_PARAMETER_DUMP</p>
<p>On voit bien qu'il n y a pas eu de TC_LOAD_FILTER_PAR d'envoyé.</p>
<p>--> on observe sur la TM_LFR_PARAMETER_DUMP que le parametre du champ SY_LFR_PAS_FILTER_DELTA_F n est pas initialisé à la valeur par défaut.<br />Le champ contient n'importe quoi.</p>
<p>SY_LFR_PAS_FILTER_ENABLED: DISABLED = 0, SY_LFR_PAS_FILTER_MODULUS=4, SY_LFR_PAS_FILTER_TBAD=1061109567, SY_LFR_PAS_FILTER_OFFSET=0, SY_LFR_PAS_FILTER_SHIFT=1061109567, <strong>SY_LFR_PAS_FILTER_DELTA_F=257701985340,</strong> PA_LFR_RW_MASK_F0_WORD1=0xffffffff, PA_LFR_RW_MASK_F0_WORD2=0xffffffff, PA_LFR_RW_MASK_F0_WORD3=0xffffffff, PA_LFR_RW_MASK_F0_WORD4=0xffffffff, PA_LFR_RW_MASK_F1_WORD1=0xffffffff, PA_LFR_RW_MASK_F1_WORD2=0xffffffff, PA_LFR_RW_MASK_F1_WORD3=0xffffffff, PA_LFR_RW_MASK_F1_WORD4=0xffffffff, PA_LFR_RW_MASK_F2_WORD1=0xffffffff, PA_LFR_RW_MASK_F2_WORD2=0xffffffff, PA_LFR_RW_MASK_F2_WORD3=0xffffffff, PA_LFR_RW_MASK_F2_WORD4=0xffffffff, SPARE8_3=0x0</p>
<p>Les fichiers de logs (2016_12_28-09_46_13*) (sont dans le répertoire /home/validation/data/R3+/3.1.0.4/1.1.91/EM1/TESTS-UNITAIRES/send_one_update_info</p>
<p>Contexte du test<br />---------------------<br />FSW 3.1.0.4<br />VHDL 1.1.91<br />EM1 sans TIMEGEN</p> LFR-FSW - Bug #649 (Closed): CCSDS_TC_PKT_MAX_SIZE wrong: detection of a TC with wrong lengthhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6492016-03-08T07:27:00ZVeronique bouzid
<p>Le requirement suivant est passé de design a test.<br />Command packets (DPU Software to RPW analyzer flight software)<br />SSS-IF-DPS-EQ-180<br />Command packets (DPU SW to RPW analyzer SW)<br />The Analyzer Flight Software shall receive commands from the DPU Software as Telecommand<br />Source Packets according to [ES1] with a maximum length given below for each analyzer:<br />- LFR: SY_LFR_TC_MAX_LEN = <strong>228 bytes</strong> (i.e. 216 bytes of application data)</p>
<p>J'ai regardé dans ton code et toi tu testes si la longueur de la TC est < CCSDS_TC_PKT_MAX_SIZE qui vaut 255.</p>
<p>fsw_spacewire.c<br />--> lecture du buffer<br />estimatePacketslength = len -CCSDS_TC_TM_PACKET_OFFSET -3</p>
<p>-CCSDS_TC_TM_PACKET_OFFSET = 7<br />ensuite appel de la fonction tc_parser</p>
<p>cette fonction est dans le fichier tc_acceptance.c</p>
<p>*elle va verifier la longueur de la TC avec la valeur CCSDS_TC_PKT_MAX_SIZE = 255 et cela ce n est pas bon<br />WRONG_LEN_PKT
*</p>
<p>ensuite on verifie que la lg est compatible avec le subtype (tc_check_length)</p>
<p>ensuite il va envoyer uen send_tm_lfr_tc_exe_corrupted<br />il y a un champ currentTC_LEN_RCV = lg du buffer lu rangé dans un 16 bits.</p>
<p>Dans les logs voici ce que l on obtient:</p>
<p>15:56:39.56912, <b>* 32 <strong></b>, TM_LFR_TC_EXE_CORRUPTED, 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=24, (PACKET_SEQUENCE_CONTROL=0xc018), PACKET_LENGTH=25, 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=0x8000001f5a68, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xccf3, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=93, *PA_RPW_PKT_LEN_RCV_VALUE=231, PA_RPW_PKT_DATFIELDSIZE_CNT=231</strong>, PA_RPW_RCV_CRC=0x7b4, PA_RPW_COMPUTED_CRC=0x7b4</p>
<p>Les fichiers de test sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0003</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #601 (Closed): Computation of HK_LFR_LE_CNT : sometimes erroneoushttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6012016-01-30T16:53:49ZVeronique bouzid
<p>Lors de l'execution du script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0012/ccsds_time_code_format.py<br />Parfois le calcul du champ HK_LFR_LE_CNT n'est pas correct.</p>
<p>Ma question est donc <br />quand calcules tu ce champ HK_LFR_LE_CNT (au début ou à la fin de la génération de la TM_LFR_HK)? <br />est ce possible que quand tu generes une TM_LFR_HK , la tache soit interrompue et qu 'un des champs ait été incrementé</p>
<p>Voici l'extrait du fichier 2016_01_27-08_48_22-Extract.txt<br />08:47:14.123007, TM_LFR_HK, TIME=0x14250e78276b, <strong>HK_LFR_LE_CNT=121</strong>, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=60, HK_LFR_DPU_SPW_LAST_TIMC=61, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=1</strong>, HK_LFR_TIMECODE_INVALID=0, <strong>HK_LFR_TIME_TIMECODE_IT=60</strong>, HK_LFR_TIME_NOT_SYNCHRO=0, <strong>HK_LFR_TIME_TIMECODE_CTR=60</strong><br />ici on calcule 1 + 60 + 60 = 121</p>
<p>08:47:15.123013, TM_LFR_HK, TIME=0x94250e79276b, <strong>HK_LFR_LE_CNT=121</strong>, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=60, HK_LFR_DPU_SPW_LAST_TIMC=61, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=1</strong>, HK_LFR_TIMECODE_INVALID=0, <strong>HK_LFR_TIME_TIMECODE_IT=60, HK_LFR_TIME_NOT_SYNCHRO=1, HK_LFR_TIME_TIMECODE_CTR=60</strong><br />ici on calcule 1 + 60 + 1 + 60 = 122 au lieu de 121 dans le champ</p>
<p>08:47:16.122941, TM_LFR_HK, TIME=0x94250e7a94fe, <strong>HK_LFR_LE_CNT=124</strong>, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=61, HK_LFR_DPU_SPW_LAST_TIMC=62, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=1</strong>, HK_LFR_TIMECODE_INVALID=0, <strong>HK_LFR_TIME_TIMECODE_IT=61, HK_LFR_TIME_NOT_SYNCHRO=1, HK_LFR_TIME_TIMECODE_CTR=61</strong><br />ici on calcule 1+61 +1 +61 = 124</p>
<p>08:47:17.122981, TM_LFR_HK, TIME=0x94250e7b9200, <strong>HK_LFR_LE_CNT=126</strong>, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=62, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=1</strong>, HK_LFR_TIMECODE_INVALID=0, <strong>HK_LFR_TIME_TIMECODE_IT=62, HK_LFR_TIME_NOT_SYNCHRO=1, HK_LFR_TIME_TIMECODE_CTR=62</strong><br />ici on calcule 1+62 +1 +62 = 126</p>
<p>Les fichiers de test ( 2016_01_27-08_48_22*) se trouvent dans /home/validation/data/R3/3.0.0.14/1.1.89/SVS-0012<br />Contexte du test<br />----------------------<br />FSW 3.0.0.14<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #560 (Closed): activer la vérification du cache du Leon3FThttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5602015-11-04T04:43:52ZVeronique bouzid
<p>Lors de la vérification de l'activation du cache Alexis a posé la question suivante à Paul:</p>
<p>"J'ai trouvée ça dans la doc(grip p822 70.11.4 Cache control register) pour le cache: 20:19 FT scheme (FT) - “00” = no FT, “01” = 4-bit checking implemented. Tu l'actives?"</p>
<p>La réponse de Paul<br /> Ma réponse était non. Il faudra que je le fasse pour une utilisation dans le cadre FT.</p>
<p>Il faut donc implemeter cette fonctionalité et mettre à jour la SRS en conséquence.<br />Il reste à déterminer comment valider la mise en place de cette fonctionalité (Alexis et Véronique!!)</p> LFR-FSW - Bug #533 (Closed): Champs PA_BIA_ON_OFF AND al de TM_LFR_SCIENCE_SBM2_BP*_F* ne sont pa...https://hephaistos.lpp.polytechnique.fr/redmine/issues/5332015-10-04T15:21:23ZVeronique bouzid
<p>Si on change la valeur du paramètre CP_PDU_BIAS_ON_OFF ( 0 vers 1) dans TC_LFR_UPDATE_INFO, on s'attend à voir ce parametre mis à jour dans les TM_LFR_SCIENCE<br />produites après la prise en compte de la TC_LFR_UPDATE_INFO. Le champ se nomme PA_BIA_ON_OFF dans TM_LFR_SCIENCE_SBM2_BP*.</p>
<p>hors ce n'est pas le cas.</p>
<p>Voici liste des champs de TC_LFR_UPDATE_INFO qui ne sont recopiés dans les TM_LFR_SCIENCE_SBM2_BP*_F0 <br />- CP_PDU_BIAS_ON_OFF<br />- PA_BIA_MODE_MUX_SET<br />- PA_BIA_MODE_HV_ENABLED<br />- PA_BIA_MODE_BIAS1_ENABLED<br />- PA_BIA_MODE_BIAS2_ENABLED<br />- PA_BIA_MODE_BIAS3_ENABLED</p>
<p>le script joué se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0038/update_info_sbm2.py</p>
<p>Les fichiers (2015_10_03-13_01_48*) sont rangés dans le répertoire /home/validation/data/R3/3.0.0.9/1.1.89/SVS-0038/sbm2</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.9<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #532 (Closed): champs PA_BIA_ON_OFF AND al de toutes les TM_LFR_SCIENCE_SBM1_* ne s...https://hephaistos.lpp.polytechnique.fr/redmine/issues/5322015-10-04T15:10:56ZVeronique bouzid
<p>Bug signalé depuis dans JIRA : <br /><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWMEB-508">https://jira-lesia.obspm.fr/browse/RPWMEB-508</a><br />-------------------------<br />Si on change la valeur du paramètre CP_PDU_BIAS_ON_OFF ( 0 vers 1) dans TC_LFR_UPDATE_INFO, on s'attend à voir ce parametre mis à jour dans les TM_LFR_SCIENCE<br />produites après la prise en compte de la TC_LFR_UPDATE_INFO. Le champ se nomme PA_BIA_ON_OFF dans TM_LFR_SCIENCE_SBM1_BP*.</p>
<p>hors ce n'est pas le cas.</p>
<p><ins>Voici liste des champs de TC_LFR_UPDATE_INFO qui ne sont recopiés dans les TM_LFR_SCIENCE_SBM1_BP*_F0 et TM_LFR_SCIENCE_SBM1_CWF_F1</ins><br />- CP_PDU_BIAS_ON_OFF<br />- PA_BIA_MODE_MUX_SET<br />- PA_BIA_MODE_HV_ENABLED<br />- PA_BIA_MODE_BIAS1_ENABLED<br />- PA_BIA_MODE_BIAS2_ENABLED<br />- PA_BIA_MODE_BIAS3_ENABLED</p>
<p>le script joué se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0038/update_info_sbm1.py</p>
<p>Les fichiers (2015_10_03-12_04_31*) sont rangés dans le répertoire /home/validation/data/R3/3.0.0.9/1.1.89/SVS-0038/sbm1</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.9<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #531 (Closed): champs PA_BIA_ON_OFF AND al de TM_LFR_SCIENCE_BURST_BP*_F* ne sont p...https://hephaistos.lpp.polytechnique.fr/redmine/issues/5312015-10-04T15:00:31ZVeronique bouzid
<p>Bug signalé depuis dans JIRA : <br /><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWMEB-508">https://jira-lesia.obspm.fr/browse/RPWMEB-508</a><br />-------------------------<br />Si on change la valeur du paramètre CP_PDU_BIAS_ON_OFF ( 0 vers 1) dans TC_LFR_UPDATE_INFO, on s'attend à voir ce parametre mis à jour dans les TM_LFR_SCIENCE<br />produites après la prise en compte de la TC_LFR_UPDATE_INFO. Le champ se nomme PA_BIA_ON_OFF dans TM_LFR_SCIENCE_BURST_BP* .</p>
<p>hors ce n'est pas le cas.</p>
<p>Voici liste des champs de TC_LFR_UPDATE_INFO qui ne sont recopiés dans les TM_LFR_SCIENCE_BURST_BP*<br />- CP_PDU_BIAS_ON_OFF<br />- PA_BIA_MODE_MUX_SET<br />- PA_BIA_MODE_HV_ENABLED<br />- PA_BIA_MODE_BIAS1_ENABLED<br />- PA_BIA_MODE_BIAS2_ENABLED<br />- PA_BIA_MODE_BIAS3_ENABLED</p>
<p>le script joué se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0038/update_info_burst.py</p>
<p>Les fichiers (2015_10_03-11_19_22) sont rangés dans le répertoire /home/validation/data/R3/3.0.0.9/1.1.89/SVS-0038/burst</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.9<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #508 (Closed): Field DESTINATION_ID into TM_LFR_KCOEFFICIENTS_DUMP non complianthttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5082015-09-24T14:08:47ZVeronique bouzid
<p>Le champ DESTINATION_ID = le champ SOURCE_ID de la TC_LFR envoyée<br />Ce n'est pas le cas, DESTINATION_ID = 0</p>
<p>14:50:23.011819, <strong>TC_LFR_DUMP_KCOEFFICIENTS</strong>, 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=11420, (PACKET_SEQUENCE_CONTROL=0xec9c), PACKET_LENGTH=5, 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: DUMP_KCOEFFICIENTS = 95, <strong>SOURCE_ID: AOCS = 11</strong>, CRC = 0x19af</p>
<p>14:50:23.045264, <strong>TM_LFR_KCOEFFICIENTS_DUMP</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=11, (PACKET_SEQUENCE_CONTROL=0xc00b), PACKET_LENGTH=3913, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, <strong>DESTINATION_ID: GROUND = 0</strong>, TIME=0x8000037bec96, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT: 2, PA_LFR_KCOEFF_PKT_NR: 1 , PA_LFR_KCOEFF_BLK_NR: 30 , SY_LFR_KCOEFF_FREQUENCY: 0 , SY_LFR_KCOEFF_1:1065353216 , SY_LFR_KCOEFF_2:1065353216 , SY_LFR_KCOEFF_3:1065353216 , SY_LFR_KCOEFF_4:1065353216 , SY_LFR_KCOEFF_5:1065353216 , SY_LFR_KCOEFF_6:1065353216 , SY_LFR_KCOEFF_7:1065353216 , SY_LFR_KCOEFF_8:1065353216 , ...</p>
<p>le script joué est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0018/source_id_loop_step1.py<br />le fichier detail /home/validation/data/R3/3.0.0.8/1.1.89/SVS-0018/2015_09_23-14_51_13-Detail.txt</p>
<p>Contexte du test<br />----------------<br />----------------<br />FSW 3.0.0.8<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #456 (Closed): champs PA_BIA_ON_OFF AND al de TM_LFR_SCIENCE_NORMAL_BP*_F* ne sont...https://hephaistos.lpp.polytechnique.fr/redmine/issues/4562015-07-02T11:02:49ZVeronique bouzid
<p>Bug signalé depuis dans JIRA : <br /><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWMEB-508">https://jira-lesia.obspm.fr/browse/RPWMEB-508</a><br />-------------------------<br />Si on change la valeur du paramètre CP_PDU_BIAS_ON_OFF ( 0 vers 1) dans TC_LFR_UPDATE_INFO, on s'attend à voir ce parametre mis à jour dans les TM_LFR_SCIENCE<br />produite après la prise en compte de la TC_LFR_UPDATE_INFO. Le champ se nomme PA_BIA_ON_OFF dans TM_LFR_SCIENCE_NORMAL_BP* .</p>
<p>hors ce n'est pas le cas.</p>
<p>les logs<br />09:36:47.673516, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)<br />09:36:47.695604, TM_LFR_TC_EXE_SUCCESS, TIME=0x80000009fae2<br />09:36:48.696052, TC_LFR_UPDATE_INFO,*CP_PDU_BIAS_ON_OFF: ON = 1*<br />09:36:48.909631, TM_LFR_HK,HK_LFR_UPDATE_INFO_TC_CNT=1 --> prise en compte de TC_LFR_UPDATE_INFO</p>
<p>le premier BP ne voit rien, ce qui peut s'explique car l acquisition a pu commence avant la prise en compte deTC_LFR_UPDATe_INFO<br />09:36:51.738856, <strong>TM_LFR_SCIENCE_NORMAL_BP1_F0</strong>, TIME=0x80000009fadf, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong>, SPARE=0x0, SY_LFR_BW=1, SY_LFR_SP0=0, SY_LFR_SP1=0, SY_LFR_R0=0, SY_LFR_R1=0, SY_LFR_R2=0, PA_LFR_ACQUISITION_TIME=0x80000009fadf, SPARE=0x0, PA_LFR_N_BP1_BLK_NR_F0=11</p>
<p>malheureusement il n est jamais pris en compte aussi bien sur les BP1 que sur les BP2</p>
<p>09:36:55.738969, TM_LFR_SCIENCE_NORMAL_BP1_F0, <strong>TIME=0x8000000dfade</strong>, PA_LFR_SID_PKT: SC_N_BP1_F0 = 14, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>09:36:55.751354, TM_LFR_SCIENCE_NORMAL_BP1_F1, <strong>TIME=0x8000000dfaeb</strong>, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong>,</p>
<p>09:36:55.764467, TM_LFR_SCIENCE_NORMAL_BP1_F2, <strong>TIME=0x8000000dfbd0</strong>, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong>,</p>
<p>BP2<br />09:37:07.755408, TM_LFR_SCIENCE_NORMAL_BP2_F0, <strong>TIME=0x80000019fad9</strong>, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>09:37:07.75807, TM_LFR_SCIENCE_NORMAL_BP2_F1,*TIME=0x80000019fae6*, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>09:37:07.781859, TM_LFR_SCIENCE_NORMAL_BP2_F2, <strong>TIME=0x80000019fbcc</strong>, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>Idem pour les parametres <br />CP_BIA_MODE_MUX_SET, CP_BIA_MODE_HV_ENABLED, CP_BIA_MODE_BIAS1_ENABLED, CP_BIA_MODE_BIAS2_ENABLED, CP_BIA_MODE_BIAS3_ENABLED<br />correspondant à <br />PA_BIA_MODE_MUX_SET, PA_BIA_MODE_HV_ENABLED, PA_BIA_MODE_BIAS1_ENABLED, PA_BIA_MODE_BIAS2_ENABLED, PA_BIA_MODE_BIAS3_ENABLED.</p>
<p>le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0077/update_info_cnt_normal.py</p>
<p>les fichiers de log (2015_07_02-09_42_14*) se trouvent dans /home/validation/data/R3/3.0.0.7/SVS-0077/normal.</p>
<p>Pour l'instant le script n'a testé que les BP en Normal mode. Reste à verifier les autres produits ....</p>
<p>Ce comportement n'est pas en conformité avec ce que Paul écrit dans sa doc <strong>SDD p35 req-lfr-srs-55_ed1</strong></p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.7<br />VHDL 1.1.83 (_c car chgt de contrainte sur timing)<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #424 (Closed): Dysfonctionnement sur le test SVS-0018 (/opt/VALIDATION_R2/lfrverif/...https://hephaistos.lpp.polytechnique.fr/redmine/issues/4242015-06-02T14:38:32ZVeronique bouzid
<p>Le lancement du test /opt/VALIDATION_R2/lfrverif/LFR_SVS/SVS-0018/source_id_loop_step1.py commence normalement par une tempo<br />de 1s pour avant d'envoyer tc_lfr_enter_mode dans le mode standby.<br />Hors voici ce que l on observe:</p>
<p>19:48:45.341109, TM_LFR_HK, TIME=0x80000af9325e<br />19:48:45.344858, TM_LFR_HK, TIME=0x80000afa325f<br />19:48:45.34524, TM_LFR_HK, TIME=0x80000afb325e<br />19:48:45.345658, TM_LFR_HK, TIME=0x80000afc325e<br />19:48:45.346815, TM_LFR_HK, TIME=0x80000afd325e<br />19:48:45.350134, TM_LFR_HK, TIME=0x80000afe325e<br />19:48:45.350745, TM_LFR_HK, TIME=0x80000aff325e<br />19:48:45.35197, TM_LFR_HK, TIME=0x80000b00325e<br />19:48:45.352599, TM_LFR_HK, TIME=0x80000b01325e<br />19:48:45.353048, TM_LFR_HK, TIME=0x80000b02325e<br />19:48:45.353499, TM_LFR_HK, TIME=0x80000b03325e<br />19:48:45.353802, TM_LFR_HK, TIME=0x80000b04325f<br />19:48:45.354074, TM_LFR_HK, TIME=0x80000b05325e<br />19:48:46.200787, TM_LFR_HK, TIME=0x80000b06325e</p>
<p>Le temps internes des HK est correct, mais pas le temps de reception.</p> LFR-FSW - Bug #362 (Closed): CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000 https://hephaistos.lpp.polytechnique.fr/redmine/issues/3622015-03-10T11:44:13ZVeronique bouzid
<p>Le systeme est à l heure (setTime.py),<br />on joue le script /home/validation/SCRIPT/just_normal_mode.py quijoue le Normal Mode durant 2h 1mn</p>
<p>La premiere salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 montre un mauvais champ PA_LFR_ACQUISITION_TIME qui vaut 0x000000000000.</p>
<p>11:42:31.207358, TC_LFR_ENTER_MODE, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000000000<br />11:42:31.239434, TM_LFR_TC_EXE_SUCCESS, TIME=0x1c7f20255cad<br />11:45:19.192084, TM_LFR_SCIENCE_NORMAL_CWF_F3, <strong>PA_LFR_ACQUISITION_TIME=0x000000000000</strong><br />11:45:19.232713, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x0000002a0000<br />11:45:19.264199, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x000000540000<br />11:45:19.278873, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x0000007e0000<br />Le delta entre chaque TM_LFR_SCIENCE_NORMAL_CWF_F3 est bon (2a = 42s).</p>
<p>Par contre la deuxieme salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 est correcte<br />11:48:06.886975, TM_LFR_HK, TIME=0x1c7f21750170, HK_LFR_MODE: NORMAL = 1<br />11:48:07.190201, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f20cd4c2e<br />11:48:07.211115, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f20f74c2e<br />11:48:07.242629, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f21214c2e<br />11:48:07.255938, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f214b4c2e</p>
<p>Les fichiers résultats sont dans /home/validation/data/R2+/JUST-NORMAL</p>
<p>Contexte du test<br />-----------------<br />FSW 2.0.2.2<br />VHDL 1.1.63<br />EM 1<br />SocExplorer 0.4.7 (attention s affiche 0.4.5 dans le fichier Nb.txt)<br />StarDundee spacewire<br />Mini-LFR n°5 en mode TIMEGEN</p> LFR-FSW - Bug #354 (Closed): Bit HK_LFR_CALIB_ENABLED n'est pas géréhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3542015-03-06T10:33:38ZVeronique bouzid
<p>Lancement du script /opt/VALIDATION_R2/lfrverif/LFR_SVS/SVS-0003/loop_tm_lfr_tc_exe.py</p>
<p>Suite à l'envoi d'un TC_LFR_ENABLE_CALIBRATION et de TM_LFR_TC_EXE_SUCCESS, le paquet TM_LFR_HK montre que le bit HK_LFR_CALIB_ENABLED est à 0</p>
<p>14:29:40.226556, TC_LFR_ENABLE_CALIBRATION<br />14:29:40.238556, TM_LFR_TC_EXE_SUCCESS<br />14:29:40.317008, TM_LFR_HK,HK_LFR_CALIB_ENABLED: DISABLED = 0</p>
<p>De meme l'envoi de la commande TC_LFR_DISABLE_CALIBRATION ne permet pas de verifier que le bit est remis à zéro.</p>
<p>Contexte de test<br />FSW 2.0.2.2<br />VHDL 1.1.63<br />EM 1<br />SocExplorerEngine.getSocExplorer: Version = 0.4.5, Branch = default, Changeset = c4b98d42ee59<br />StarDundee spacewire<br />Mini-LFR n°5 en mode TIMEGEN</p>