INSTRU: Issues
https://hephaistos.lpp.polytechnique.fr/redmine/
https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?1508097601
2018-10-03T15:24:43Z
Redmine
Redmine
LFR-FSW - Bug #3121 (Closed): Analyse Logiscope LFR_3.2.0.21 : LFR_basic-parameters : Tr_OperCond...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/3121
2018-10-03T15:24:43Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_OperCond<br />Definition:<br />-----------<br />The conditional operator ? ... : ... must not be used.</p>
<p>La règle n'est pas respectée dans 2 cas d'après Logiscope:<br />basic_parameters.h : line 363 : tmp_uint8 = (e_cross_b_im > e_cross_b_re) ? 0x40 : 0x00;<br />basic_parameters.h : line 479 : tmp_uint8 = (n_cross_e_scal_b_im > n_cross_e_scal_b_re) ? 0x40 : 0x00;</p>
LFR-FSW - Bug #1744 (Closed): Corrections QA pour relivraison DATAPACK R3++ updated
https://hephaistos.lpp.polytechnique.fr/redmine/issues/1744
2017-07-07T14:11:40Z
bruno katra
<p>Ci-dessous l'ensemble des bugs QA à corriger pour DP R3++ updated attendu pour fin Aout 2017:</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-574">https://jira-lesia.obspm.fr/browse/RPWSWR-574</a> : pas compris ce qu'il fallait faire...</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-712">https://jira-lesia.obspm.fr/browse/RPWSWR-712</a></p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-713">https://jira-lesia.obspm.fr/browse/RPWSWR-713</a></p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-710">https://jira-lesia.obspm.fr/browse/RPWSWR-710</a></p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-706">https://jira-lesia.obspm.fr/browse/RPWSWR-706</a> : Mise à jour des tailles de l'exe.</p>
<p>- <del><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-625">https://jira-lesia.obspm.fr/browse/RPWSWR-625</a> * ==> RFW à faire avec Bruno + document fourni à Milan (en pj dans JIRA)*</del> REASSIGNé à BRUNO</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-627">https://jira-lesia.obspm.fr/browse/RPWSWR-627</a> : mettre à jour le texte de la RFW</p>
<p>- <a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-633">https://jira-lesia.obspm.fr/browse/RPWSWR-633</a> : documents à signer par les concernés</p>
LFR-FSW - Bug #966 (Closed): Comment valider le SSS-CP-EQS-526
https://hephaistos.lpp.polytechnique.fr/redmine/issues/966
2017-03-10T13:24:12Z
Veronique 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 #957 (Closed): Erroneous PA_LFR_RW_MASK_F2_WORD2 on TM_LFR_PARAMETER_DUMP when R...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/957
2017-03-03T15:05:34Z
Veronique bouzid
<p>A nouveau, la fonction de calcul de masque ne donne pas la bonne valeur.<br />Le script utilisé /home/validation/SCRIPT/R3++/test_rw_one_freq_96.py envoie une TC_LFR_UPDATE_INFO avec CP_RPW_SC_RW1_F1 à 96.0 hz et nan dans toutes les autres valeurs.</p>
<p>Aucune TC_LOAD_FILTER_PAR n a ete envoyée.</p>
<p>13:46:33.997939, TC_LFR_UPDATE_INFO, <strong>CP_RPW_SC_RW1_F1=1119944703</strong>, CP_RPW_SC_RW1_F2=2147483647, CP_RPW_SC_RW1_F3=2147483647, CP_RPW_SC_RW1_F4=2147483647, CP_RPW_SC_RW2_F1=2147483647, CP_RPW_SC_RW2_F2=2147483647, CP_RPW_SC_RW2_F3=2147483647, CP_RPW_SC_RW2_F4=2147483647, CP_RPW_SC_RW3_F1=2139160575, CP_RPW_SC_RW3_F2=2147483647, CP_RPW_SC_RW3_F3=2147483647, CP_RPW_SC_RW3_F4=2147483647, CP_RPW_SC_RW4_F1=2147483647, CP_RPW_SC_RW4_F2=2147483647, CP_RPW_SC_RW4_F3=2147483647, CP_RPW_SC_RW4_F4=2147483647</p>
<p>La TM_LFR_HK positionne correctement le flag a enabled<br />13:46:34.693412, TM_LFR_HK, <strong>HK_LFR_SC_RW1_F1_FLAG: ENABLED = 1</strong>, HK_LFR_SC_RW1_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F4_FLAG: DISABLED = 0</p>
<p>La TM_LFR_PARAMETER_DUMP montre les masques calculés<br />13:46:37.001817, TM_LFR_PARAMETER_DUMP,<br /> 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=0xfffffffc, 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=0xffffff8f, PA_LFR_RW_MASK_F2_WORD1=0xfffffffe, <strong>PA_LFR_RW_MASK_F2_WORD2=0x7fffffff,</strong> PA_LFR_RW_MASK_F2_WORD3=0xffffffff, PA_LFR_RW_MASK_F2_WORD4=0xffffffff</p>
<p>Hors si on regarde le <a class="issue tracker-1 status-5 priority-5 priority-highest closed" title="Bug: Fonction setFBinMask: Calcul masque erroné (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/867">#867</a> les masques avaient été correctement calculés et montraient<br />PA_LFR_RW_MASK_F2_WORD2=0x3fffffff</p>
<p>Les fichiers de logs (2017_03_03-13_46_44*) se trouvent dans le répertoire /home/validation/data/R3++/3.2.0.2/1.1.91/TEST-UNITAIRES/test_rw_one_freq_96</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.2<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p>
LFR-FSW - Bug #939 (Closed): Negative RW Frequency send into TC_LFR_UPDATE_INFO is taken in account
https://hephaistos.lpp.polytechnique.fr/redmine/issues/939
2017-02-15T14:10:36Z
Veronique bouzid
<p>J ai classé en Bug ce test mais je ne suis pas sure !!!</p>
<p>Ce test envoie une frequence negative (-1.0) dans le champ CP_RPW_SC_RW1_F1 de la TC_LFR_UPDATE_INFO</p>
<p>14:45:59.204015, TC_LFR_UPDATE_INFO, 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=103, 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: UPDATE_INFO = 51, SOURCE_ID: MISSION_TIMELINE = 110, CP_PDU_SCM_ON_OFF: OFF = 0, CP_PDU_ANT3_ON_OFF: OFF = 0, CP_PDU_ANT2_ON_OFF: OFF = 0, CP_PDU_ANT1_ON_OFF: OFF = 0, CP_PDU_THR_ON_OFF: OFF = 0, CP_PDU_TDS_ON_OFF: OFF = 0, CP_PDU_LFR_ON_OFF: OFF = 0, CP_PDU_BIAS_ON_OFF: OFF = 0, CP_BIA_MODE_MUX_SET: SET_0 = 0, CP_BIA_MODE_HV_ENABLED: DISABLED = 0, CP_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, CP_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, CP_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, SPARE: 0x0, CP_BIA_BIAS1=614.578487(uA), CP_BIA_BIAS2=614.56492241(uA), CP_BIA_BIAS3=614.55125782(uA), CP_BIA_M1=26.223070035(V), CP_BIA_M2=-27.673988037(V), CP_BIA_M3=28.973391609(V), CP_BIA_PHV=-3.282354, CP_BIA_NHV=18.600006, CP_BIA_TEMP_ANT1_LF_PA=-1756.0849565, CP_BIA_TEMP_ANT2_LF_PA=-6703.2503965, CP_BIA_TEMP_ANT3_LF_PA=-6703.2503965, CP_BIA_TEMP_PCB=-6703.2503965, SPARE=0x0, CP_LFR_MODE_COPY: STANDBY = 0, CP_LFR_CALIB_ENABLED: DISABLED = 0, CP_TDS_MODE_COPY: STANDBY = 0, CP_THR_MODE_COPY: STANDBY = 0, CP_LFR_TEMP_SCM=256degC, CP_THR_TEMP_ANT1_HF_PA=7531, CP_THR_TEMP_ANT2_HF_PA=14725, CP_THR_TEMP_ANT3_HF_PA=25836, CP_RPW_SC_RW1_F1=3212836864,</p>
<p>La TC_LFR_UPDATE_INFO est prise en compte, le compteur HK_LFR_UPDATE_INFO_TC_CNT est incrementé dans TM_LFR_HK . La valeur négative n est donc pas interdite.<br />On va verifier les masques dans TM_LFR_PARAMETER_DUMP.<br />A_LFR_RW_MASK_F0_WORD1=0xffffffff, PA_LFR_RW_MASK_F0_WORD2=0xffffffff, PA_LFR_RW_MASK_F0_WORD3=0xffffffff, <strong>PA_LFR_RW_MASK_F0_WORD4=0xfffffffe</strong>, PA_LFR_RW_MASK_F1_WORD1=0xffffffff, PA_LFR_RW_MASK_F1_WORD2=0xffffffff, PA_LFR_RW_MASK_F1_WORD3=0xffffffff, <strong>PA_LFR_RW_MASK_F1_WORD4=0xfffffffe,</strong> 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</p>
<p>On voit qu il a été mis à jour pour F0 et que ce masque positionne le bits de poids faible à 0 et également dans PA_LFR_RW_MASK_F1_WORD4.<br />EST CE UN BUG OU PAS?<br />Quel est notre comportement dans ce cas?</p>
<p>Le script est /home/validation/SCRIPT/R3++/test_rw_one_neg_freq.py et les fichiers (2017_02_15-14_46_09*) sont rangés dans le répertoire<br />/home/validation/data/R3++/3.2.0.1/1.1.91/TESTS-UNITAIRES/one_neg_freq.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.1<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p>
LFR-FSW - Bug #897 (Closed): Analyse Logiscope LFR_3.1.0.4 modifiée tag 322 (c0603702c8c8) : Do...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/897
2017-01-13T16:00:08Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_ArtVariables</p>
<p>Definition:<br />-----------<br />The key-word union is not allowed.</p>
<p>La règle n'est pas respectée dans 2 cas :<br />ccsds_types.h : lignes 803, 833 (code ajouté das cette version)</p>
LFR-FSW - Bug #814 (Closed): Analyse Logiscope LFR_3.1.0.4 : metric Number of direct calls
https://hephaistos.lpp.polytechnique.fr/redmine/issues/814
2016-10-19T13:39:17Z
William Recart
william.recart@lpp.polytechnique.fr
<p>La métriqueNumber of direct calls doit etre inférieure à 20.</p>
<p>Le métrique est non respectée dans 0.79% des cas :<br />Init (rtems_task_argument) => 38<br />actn_task (rtems_task_argument) => 21</p>
LFR-FSW - Bug #813 (Closed): Analyse Logiscope LFR_3.1.0.4 : metric Cyclomatic number
https://hephaistos.lpp.polytechnique.fr/redmine/issues/813
2016-10-19T13:36:39Z
William Recart
william.recart@lpp.polytechnique.fr
<p>La métrique Cyclomatic number doit etre inférieure à 20.</p>
<p>Le métrique est non respectée dans 1.19% des cas :<br />start_all_tasks (void) => 34<br />actn_task (rtems_task_argument) => 21<br />tc_check_length (unsignedchar, unsignedint) => 33</p>
LFR-FSW - Bug #812 (Closed): Analyse Logiscope LFR_3.1.0.4 : metric Maximum nesting level
https://hephaistos.lpp.polytechnique.fr/redmine/issues/812
2016-10-19T13:30:46Z
William Recart
william.recart@lpp.polytechnique.fr
<p>La métrique Maximum nesting level doit etre inférieure à 4.</p>
<p>Le métrique est non respectée dans 1.58% des cas :<br />cwf2_task (rtems_task_argument) => 5<br />lfr_rtems_cpu_usage_report (void) => 6<br />recv_task (rtems_task_argument) => 6<br />send_task (rtems_task_argument) => 10</p>
LFR-FSW - Bug #809 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_Parenthèses Severity is Medium
https://hephaistos.lpp.polytechnique.fr/redmine/issues/809
2016-10-19T12:42:41Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_Parenthèses<br />Definition:<br />-----------<br />In expressions, every binary and ternary operator has to be put in parenthesis, <br />so that the evaluation priorities are not ambiguous.<br />Use the partpar option to allow the following rules: when the right operand of <br />a + or * operator uses the same operator, you can omit parenthesis for it. <br />In the same way, you can omit parenthesis in the case of the right operand of an <br />assignment operator. Moreover, you can omit parenthesis at the first level of <br />the expression.</p>
<p>Parameters:<br />----------<br />The character string "partpar", which, if used, allows programmers not to put <br />systematically parenthesis, according to the rule above.</p>
<p>Justification:<br />--------------<br />Removes ambiguity about the evaluation priorities.</p>
<p>Example:<br />--------</p>
<p>// do not write<br />result = fact / 100 + rem;</p>
<p>// write<br />result = ((fact / 100) + rem);</p>
<p>// or write, with the partpar option<br />result = (fact / 100) + rem;</p>
<p>// with the partpar option, write<br />result = (fact * ind * 100) + rem + 10 + (coeff ** c);</p>
<p>// instead of <br />result = ((fact * (ind * 100)) + (rem + (10 + (coeff ** c))));</p>
<p>La règle n'est pas respectée dans 75 cas d'après Logiscope:<br />Fichier avf0_prc0.c : ligne 378<br />Fichier avf1_prc1.c : ligne 370<br />Fichier avf2_prc2.c : ligne 256<br />Fichier fsw_misc.c : lignes 374, 705, 706, 707<br />Fichier fsw_processing.c : lignes 236, 549, 556, 584, 585, 587, 651, 654, 658, 664, 668, 702, 782, 783<br />Fichier fsw_processing.h : lignes 280, 283, 286, 306, 309<br />Fichier fsw_spacewire.c : lignes 162, 167, 267, 1586<br />Fichier tc_acceptance.c : lignes 223, 274<br />Fichier tc_handler.c : lignes 279, 365, 382, 970, 1037, 1407, 1413, 1416, 1519, 1549<br />Fichier tc_load_dump_parameters.c : lignes 403, 408, 417, 422, 431, 436, 462, 467, 551, 555, 559, 867, 885, 999, 1000, 1353, 1365, 1367, 1514<br />Fichier tm_lfr_tc_exe.c : ligne 380<br />Fichier wf_handler.c : lignes 113, 843, 905, 906, 1170, 1184, 1185, 1208, 1209, 1231, 1233, 1266, 1277</p>
LFR-FSW - Bug #807 (Closed): Analyse Logiscope LFR_3.1.0.4 : Don_Enumeration Severity is Medium
https://hephaistos.lpp.polytechnique.fr/redmine/issues/807
2016-10-19T12:36:33Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_Enumeration<br />Definition:<br />-----------<br />Numbers, characters and strings have to be declared as constants instead of being <br />used as literals inside a program. The user can list the allowed literal <br />constants.</p>
<p>Parameters:<br />-----------<br />A list of character strings representing the allowed literal constants.</p>
<p>Note: In the case of constants used in initializing lists <br />(concerning array and struct structures), only the first five violations are shown.</p>
<p>Justification:<br />--------------<br />Makes maintenance easier by avoiding the scattering of constants among the code, <br />often with the same value.</p>
<p>Example:<br />--------</p>
<p>// do not write</p>
<p>char tab<sup><a href="#fn100">100</a></sup>;<br />int i;</p>
<p>La règle n'est pas respectée dans 1435 cas d'après Logiscope:<br />Fichier avf0_prc0.c : lignes 27, 46, 83, 90, 172, 376, 377, 378, 378, 379, 380, 381, 382, 383, 384<br />Fichier avf1_prc1.c : lignes 28, 84, 91, 173, 368, 369, 370, 370, 371, 372, 373, 374<br />Fichier avf2_prc2.c : lignes 26, 72, 76, 123, 256, 269, 282<br />Fichier ccsds_types.h : lignes 303, 304, 305, 311, 313, 314, 323, 324, 325, 331, 333, 334, 335, 348, 349, 350, 356, 358, 359, 360, 363, 372, 373, 374, 380, 382, 383, 384, 395, 396, 397, 403, 405, 406, 407, 418, 419, 420, 426, 428, 429, 430, 433, 434, 435, 436, 444, 445, 446, 452, 460, 461, 469, 470, 471, 477, 483, 484, 492, 493, 494, 500, 508, 509, 517, 518, 519, 525, 531, 533, 541, 542, 543, 549, 555, 556, 564, 565, 566, 572, 580, 581, 582, 587, 592, 593, 594, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 623, 624, 625, 626, 628, 635, 636, 640, 642, 643, 644, 646, 647, 648, 687, 688, 689, 695, 705, 706, 707, 729, 730, 731, 732, 734, 735, 736, 737, 739, 740, 741, 742, 748, 750, 751, 754, 755, 756, 757, 758, 759, 760, 761, 762, 763, 764, 765, 776, 777, 778, 784, 792<br />Fichier fsw_config.c : lignes 7, 7, 8, 8, 9, 9<br />Fichier fsw_globals.c : lignes 26, 27, 28, 98<br />Fichier fsw_init.c : lignes 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 322, 323, 325, 326, 327, 332, 345, 345, 345, 345, 346, 346, 346, 346, 347, 347, 347, 347, 348, 348, 348, 348, 349, 349, 349, 349, 350, 350, 350, 350, 351, 351, 351, 351, 352, 352, 352, 352, 353, 353, 353, 353, 354, 354, 354, 354, 355, 355, 355, 355, 356, 356, 356, 356, 357, 357, 357, 357, 358, 358, 358, 358, 359, 359, 359, 359, 360, 360, 360, 360, 361, 361, 361, 361, 362, 362, 362, 362, 363, 363, 363, 363, 366, 366, 366, 366, 368, 368, 368, 368, 369, 369, 369, 369, 370, 370, 370, 370, 371, 371, 371, 371, 372, 372, 372, 372, 374, 374, 374, 374, 406, 449, 465, 481, 831, 831, 831, 831, 843, 843, 843, 843, 855, 855, 855, 855, 867, 867, 867, 867, 879, 879, 879, 879, 916, 917, 918, 919<br />Fichier fsw_init.h : lignes 19, 20<br />Fichier fsw_misc.c : lignes 28, 48, 49, 50, 51, 52, 64, 65, 66, 130, 144, 145, 146, 147, 193, 193, 193, 193, 213, 220, 264, 264, 272, 287, 291, 292, 293, 293, 294, 295, 295, 296, 354, 354, 355, 356, 357, 358, 380, 382, 386, 390, 394, 422, 429, 433, 447, 448, 452, 453, 453, 473, 474, 494, 495, 496, 496, 497, 498, 498, 499, 509, 509, 526, 530, 536, 537, 538, 538, 539, 540, 540, 541, 545, 546, 550, 551, 553, 555, 556, 556, 560, 562, 586, 587, 588, 588, 589, 589, 590, 590, 591, 591, 604, 605, 606, 606, 607, 607, 608, 608, 609, 609, 628, 640, 644, 652, 656, 664, 668, 676, 680, 686, 689, 705, 706, 707, 740, 740, 741, 743, 743, 744, 746, 746, 747, 757, 757, 811<br />Fichier fsw_params.h : lignes 276, 277, 278<br />Fichier fsw_processing.c : lignes 51, 70, 76, 78, 98, 100, 117, 128, 128, 134, 136, 156, 158, 175, 185, 185, 191, 193, 202, 208, 214, 236, 236, 238, 243, 273, 273, 279, 279, 285, 285, 360, 362, 365, 366, 369, 373, 374, 375, 375, 376, 376, 377, 377, 378, 378, 381, 382, 383, 384, 385, 386, 386, 387, 387, 388, 388, 389, 389, 390, 400, 402, 405, 406, 409, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 480, 514, 521, 521, 522, 522, 523, 523, 524, 524, 530, 531, 531, 532, 533, 533, 534, 534, 535, 535, 536, 584, 585, 605, 606, 607, 608, 609, 610, 611, 612, 613, 616, 617, 618, 619, 669, 669, 692, 699, 700, 702, 719, 723, 728, 731, 732, 733, 782, 783<br />Fichier fsw_processing.h : lignes 27, 28, 29, 35, 41, 42, 44, 53, 54, 55, 61, 67, 69, 71, 102, 103, 176, 184, 204, 205, 206, 206, 206, 207, 207, 207, 208, 208, 208, 209, 209, 209, 210, 210, 210, 211, 211, 211, 287, 287, 344<br />Fichier fsw_processing_globals.c : ligne 46<br />Fichier fsw_spacewire.c : lignes 60, 67, 125, 126, 162, 163, 194, 263, 263, 264, 264, 349, 351, 479, 539, 542, 561, 565, 768, 768, 769, 773, 773, 774, 774, 775, 775, 776, 776, 783, 785, 810, 810, 812, 820, 851, 1010, 1011, 1017, 1018, 1019, 1020, 1021, 1022, 1024, 1026, 1027, 1036, 1040, 1047, 1048, 1049, 1050, 1051, 1052, 1054, 1057, 1058, 1068, 1072, 1073, 1079, 1080, 1081, 1082, 1083, 1084, 1086, 1087, 1088, 1089, 1090, 1091, 1128, 1132, 1153, 1153, 1154, 1154, 1155, 1155, 1156, 1156, 1161, 1166, 1216, 1225, 1228, 1230, 1236, 1238, 1247, 1247, 1248, 1248, 1249, 1249, 1250, 1250, 1302, 1306, 1329, 1329, 1330, 1330, 1331, 1331, 1332, 1332, 1335, 1368, 1378, 1389, 1399, 1402, 1406, 1407, 1408, 1408, 1409, 1410, 1410, 1411, 1415, 1415, 1416, 1416, 1417, 1417, 1418, 1418, 1448, 1458, 1469, 1479, 1482, 1486, 1487, 1488, 1488, 1489, 1490, 1490, 1491, 1495, 1495, 1496, 1496, 1497, 1497, 1498, 1498, 1528, 1537, 1546, 1549, 1553, 1554, 1555, 1555, 1556, 1557, 1557, 1558, 1562, 1562, 1563, 1563, 1564, 1564, 1565, 1565, 1586, 1598<br />Fichier lfr_cpu_usage_report.c : lignes 95, 103, 104, 110<br />Fichier tc_acceptance.c : lignes 13, 28, 28, 28, 28, 42, 46, 48, 49, 51, 52, 54, 55, 57, 58, 60, 61, 63, 64, 66, 67, 87, 91, 92, 128, 128, 128, 128, 129, 130, 458, 460<br />Fichier tc_handler.c : lignes 35, 180, 265, 269, 269, 274, 279, 282, 293, 295, 360, 361, 362, 362, 363, 365, 368, 489, 502, 905, 922, 923, 928, 929, 934, 935, 940, 941, 946, 947, 952, 953, 958, 959, 964, 965, 971, 971, 972, 972, 973, 973, 974, 974, 996, 1013, 1014, 1019, 1020, 1025, 1026, 1031, 1032, 1038, 1038, 1039, 1039, 1322, 1326, 1334, 1338, 1367, 1368, 1369, 1370, 1371, 1371, 1373, 1376, 1378, 1379, 1380, 1381, 1392, 1395, 1396, 1397, 1398, 1400, 1403, 1405, 1406, 1407, 1407, 1411, 1413, 1413, 1414, 1414, 1415, 1415, 1416, 1416, 1417, 1417, 1425, 1429, 1438, 1442, 1451, 1455, 1482, 1488, 1508, 1510, 1514, 1514, 1515, 1515, 1516, 1516, 1517, 1517, 1519, 1521, 1538, 1540, 1544, 1544, 1545, 1545, 1546, 1546, 1547, 1547, 1549, 1551, 1618, 1618, 1626, 1630<br />Fichier tc_load_dump_parameters.c : lignes 108, 117, 130, 175, 184, 192, 192, 195, 240, 249, 262, 334, 334, 335, 335, 339, 339, 340, 340, 343, 343, 344, 344, 350, 408, 422, 428, 436, 441, 442, 443, 443, 444, 445, 445, 446, 460, 462, 463, 467, 472, 473, 474, 474, 475, 476, 476, 477, 511, 512, 513, 513, 514, 515, 515, 516, 551, 555, 559, 570, 572, 578, 580, 589, 598, 608, 617, 627, 988, 996, 999, 1000, 1023, 1028, 1033, 1034, 1045, 1053, 1056, 1059, 1063, 1064, 1065, 1065, 1073, 1081, 1087, 1091, 1093, 1095, 1101, 1103, 1107, 1107, 1110, 1110, 1113, 1113, 1116, 1116, 1119, 1119, 1122, 1122, 1125, 1128, 1133, 1144, 1167, 1215, 1216, 1217, 1222, 1247, 1247, 1249, 1255, 1255, 1258, 1258, 1266, 1268, 1275, 1275, 1278, 1278, 1317, 1364, 1365, 1383, 1383, 1384, 1384, 1394, 1395, 1413, 1417, 1424, 1425, 1426, 1426, 1427, 1428, 1428, 1429, 1439, 1441, 1443, 1468, 1472, 1473, 1483, 1489, 1490, 1490, 1495, 1496, 1498, 1503, 1504, 1506, 1514, 1514, 1520, 1524, 1531, 1532, 1533, 1533, 1534, 1534, 1535, 1535, 1536, 1536, 1539, 1546, 1548, 1611, 1612, 1616<br />Fichier tm_lfr_tc_exe.c : lignes 44, 47, 54, 55, 56, 56, 57, 58, 58, 59, 109, 112, 119, 120, 121, 121, 122, 123, 123, 124, 126, 177, 180, 187, 188, 189, 189, 190, 191, 191, 192, 194, 245, 248, 255, 256, 257, 257, 258, 259, 259, 260, 262, 311, 314, 321, 322, 323, 323, 324, 325, 325, 326, 328, 379, 380, 388, 391, 398, 399, 400, 400, 401, 402, 402, 403, 405, 497, 498, 502<br />Fichier wf_handler.c : lignes 64, 67, 89, 118, 118, 121, 121, 125, 127, 127, 131, 145, 145, 160, 162, 172, 185, 185, 191, 191, 197, 199, 199, 204, 212, 212, 216, 216, 221, 223, 223, 228, 236, 236, 241, 241, 246, 248, 248, 253, 286, 286, 288, 288, 400, 401, 405, 416, 417, 417, 455, 470, 490, 578, 679, 679, 680, 680, 681, 681, 682, 682, 698, 701, 703, 704, 705, 705, 706, 707, 707, 708, 710, 711, 712, 712, 713, 713, 714, 714, 715, 720, 720, 724, 724, 728, 728, 732, 732, 736, 736, 740, 740, 744, 744, 748, 748, 753, 759, 760, 761, 761, 762, 762, 763, 763, 764, 791, 792, 793, 794, 807, 808, 810, 813, 814, 818, 819, 838, 850, 850, 850, 851, 851, 851, 854, 855, 856, 856, 856, 857, 857, 857, 861, 898, 899, 900, 905, 905, 906, 906, 914, 914, 919, 919, 931, 933, 933, 939, 944, 944, 950, 967, 1018, 1029, 1094, 1095, 1096, 1100, 1120, 1120, 1121, 1121, 1122, 1123, 1124, 1124, 1125, 1125, 1144, 1145, 1148, 1149, 1152, 1170, 1173, 1184, 1185, 1185, 1185, 1185, 1185, 1185, 1188, 1208, 1209, 1209, 1209, 1209, 1209, 1209, 1231, 1233, 1292, 1293, 1297<br />Fichier wf_handler.h : ligne 33</p>
LFR-FSW - Bug #801 (Closed): Analyse Logiscope LFR_3.1.0.4 : Don_Initialisation_P2 Severity is High
https://hephaistos.lpp.polytechnique.fr/redmine/issues/801
2016-10-19T12:13:09Z
William Recart
william.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_Initialisation_P2 :<br />Definition:<br />-----------<br />All variables must be initialized before they are used, without aking into account<br />on the default value attributed by the compiler.<br />Global variables, parameters of a function in the function body, and data fields <br />of a class in its methods are considered to be initialized.</p>
<p>Justification:<br />--------------<br />Not all compilers give the same default values. Unexpected behaviour can be <br />avoided with better control over variable values.</p>
<p>Limitations:<br />------------<br />This rule is not violated in the following cases: <br />If an array, a struct or a class are used, they will be consided initialized as <br />soon as a part of them has been initialized.<br />For example: <br /> int a<sup><a href="#fn2">2</a></sup>;<br /> int b<sup><a href="#fn2">2</a></sup> = {6, 7};<br /> int h;</p>
<pre><code>a[0] = b[0]; // ok<br /> h = a[1]; // ok</code></pre>
<pre><code>struct
{<br /> int i;<br /> int j;<br /> } e, f;</code></pre>
<pre><code>e.i = 0;<br /> g = e; // ok</code></pre>
<p>This rule is violated in the following cases where initialization is uncertain:</p>
<p>Using a variable in a function call is considered as "being used": if it is not <br />initialized, the rule will be violated. <br />This will occur whatever the use of the function, even initializing the variable.</p>
<p>In cases including a conditional initialization, the rule is violated even though <br />the variable may well be initialized. </p>
<pre><code>int i, j, k;<br /> j = func();<br /> if (j)<br /> i = 0;<br /> k = i; // violation</code></pre>
<p>This applies even when there is an else branch, for example in<br /> int i, j, k;<br /> j = func();<br /> if (j)<br /> i = 0;<br /> else <br /> i = 5;<br /> k = i; // violation <br />where initialization is certain.</p>
<p>In the case of a loop, for example<br />int j, k;<br />for (int i=0; i<glob; i++)
{<br /> j=func(i);<br /> }<br />k = j; // violation <br />where glob is a global variable, depending on the value of glob, j will have been <br />initialized or not: the rule is violated, even if the loop condition occurs or not.</p>
<p>La règle n'est pas respectée dans 352 cas d'après Logiscope:<br />Fichier avf0_prc0.c : lignes 70, 77, 174, 207, 210, 218, 221, 227, 230, 236, 239, 248, 253, 262, 262, 287, 289, 290, 293, 300, 302, 303, 306, 325, 327, 328, 331, 337, 339, 340, 343, 357, 360, 366<br />Fichier avf1_prc1.c : lignes 71, 78, 175, 208, 211, 219, 222, 228, 231, 240, 245, 254, 254, 279, 281, 282, 285, 292, 294, 295, 298, 317, 319, 320, 323, 329, 331, 332, 335, 349, 352, 358<br />Fichier avf2_prc2.c : lignes 59, 66, 125, 156, 159, 163, 168, 177, 177, 202, 204, 205, 208, 216, 218, 219, 222, 238, 244<br />Fichier fsw_init.c : lignes 274, 278, 743, 752, 761, 770, 779, 805, 891, 893<br />Fichier fsw_misc.c : lignes 30, 195, 210, 235, 260, 262, 270, 323, 378, 379, 565, 567, 802, 802, 803, 803, 805, 806, 807, 808<br />Fichier fsw_processing.c : ligne 574<br />Fichier fsw_spacewire.c : lignes 45, 59, 60, 66, 67, 136, 142, 152, 166, 173, 173, 175, 175, 184, 186, 186, 188, 193, 193, 199, 240, 250, 250, 259, 314, 329, 346, 348, 349, 352, 406, 522, 588, 611, 613, 615, 617, 619, 621, 623, 625, 627, 629, 631, 649, 674, 674, 681, 681, 688, 688, 695, 695, 702, 702, 709, 709, 716, 716, 723, 723, 730, 730, 737, 737, 744, 744, 754, 754, 757, 1122, 1124, 1125, 1208, 1209, 1211, 1296, 1298, 1299, 1360, 1362, 1363, 1440, 1442, 1443, 1520, 1522, 1523, 1586, 1586<br />Fichier lfr_cpu_usage_report.c : ligne 110<br />Fichier tc_acceptance.c : lignes 130, 130, 204, 287, 470<br />Fichier tc_handler.c : lignes 39, 45, 58, 58, 58, 67, 71, 71, 72, 72, 75, 76, 76, 79, 79, 80, 80, 83, 83, 84, 84, 87, 87, 88, 88, 91, 91, 92, 92, 95, 95, 96, 96, 99, 99, 100, 100, 103, 103, 104, 104, 107, 107, 108, 108, 111, 111, 112, 112, 115, 115, 116, 116, 119, 119, 120, 120, 123, 123, 124, 124, 127, 127, 128, 128, 131, 132, 132, 393<br />Fichier tc_load_dump_parameters.c : lignes 878, 897, 914, 1021, 1043, 1044, 1045<br />Fichier tm_lfr_tc_exe.c : lignes 379, 379<br />Fichier wf_handler.c : lignes 145, 185, 191, 197, 197, 199, 204, 204, 212, 216, 221, 221, 223, 228, 228, 236, 241, 246, 246, 248, 253, 253, 343, 354, 356, 362, 363, 364, 366, 390, 412, 421, 426, 457, 469, 471, 473, 475, 482, 523, 534, 542, 585, 586, 838, 843, 924, 953, 1183, 1207, 1230, 1264, 1290, 1293, 1293, 1295, 1301, 1303, 1303, 1307, 1313, 1313<br />Fichier : lignes</p>
LFR-FSW - Bug #397 (Closed): Parametre SY_LFR_N_SWP_P hors limite dans une TC_LFR_LOAD_NORMAL_PAR...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/397
2015-04-23T10:25:38Z
Veronique bouzid
<p>Durant le test /home/validation/data/R2+/2.0.2.3/SVS-0029<br />Sur l envoi d'une TC_LFR_LOAD_NORMAL_PAR, on positionne<br />SY_LFR_N_SWP_P = 65535<br />SY_LFR_N_ASM_P = 65535<br />SY_LFR_N_BP_P0 = 255(s), <br />SY_LFR_N_BP_P1 = 255(s)</p>
<p>la réponse à cette TC est<br />TM_LFR_TC_EXE_SUCCESS</p>
<p>Hors, la valeur max dans l ICD du parametre <strong>SY_LFR_N_SWP_P est 65528</strong> donc on aurait du obtenir une TM_LFR_TC_EXE_INCONSISTENT.<br />De plus, les valeurs SY_LFR_N_BP_P0 et SY_LFR_N_BP_P1 ne sont pas compatibles puisque SY_LFR_N_BP_P1 doit etre un multiple de SY_LFR_N_BP_P0.<br />D un point de vue ICD, ces valeurs sont conformes à l intervalle de définition mais d'un point scientifique, ce n'est pas bon.</p>
<p>Contexte du test<br />------------------</p>
<p>FSW 2.0.2.3<br />VHDL 1.1.68<br />EM 1<br />Version = 0.4.8, Branch = default, Changeset = 2c7201cecc87<br />StarDundee spacewire<br />Mini-LFR en mode TIMEGEN</p>
Solar Orbiter LFR - Bug #240 (Resolved): Liste de problèmes observés sur le LFR FGSE
https://hephaistos.lpp.polytechnique.fr/redmine/issues/240
2014-09-18T07:57:45Z
Vincent Leray
<p>Lors de l'utilisation du FGSE LFR au CNES quelques dysfontionnements ou incompréhensions dans l'utilisation sont remontés:</p>
<p>Extrait mail CNES (Cf PJ):<br />Le foreign LFR plante 9 fois sur 10 lors du lancement<br />Les courbes LFR ASM ou SWF s’affichent en superposées lors de leur sélection.<br />Nous n’arrivons pas à faire fonctionner la fonction FFT, mode d’emploi ?</p>
<p>A cela 2 Ncs ont été ouvertes:<br />NC 93 concernant l'enregistrement des ASM à F1 et F2 sur le FGSE<br />NC 102 concernant les labels des colonnes des ASMs lors d'un export.</p>
<p>Existe t il des mises à jours du FGSE prévues pour corriger ces points?</p>
LFR-FSW - Bug #84 (Closed): Talon dans la période de génération des TM_LFR_SCIENCE_x
https://hephaistos.lpp.polytechnique.fr/redmine/issues/84
2014-03-11T18:10:22Z
Gerald Saule
<p>Cette issue fait suite à Bug <a class="issue tracker-1 status-5 priority-1 priority-lowest closed" title="Bug: Analyse Logiscope LFR_3.1.0.4 : Tr_Parenthèses Severity is Medium (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/809">#809</a> (Fluctuation du délai entre deux TM_LFR_SCIENCE_NORMAL_SWF_Fx (FIRST_PACKET_OF_A_GROUP_OF_PACKETS) consécutives).</p>
<p>Actuellement, la période des TM_LFR_SCIENCE_NORMAL_SWF_Fx est 300s par défaut. C'est un paramètre modifiable; des essais sont faits avec 16s.<br />On n'observe pas de différence de cadence entre TM_LFR_SCIENCE_NORMAL_SWF_F1, TM_LFR_SCIENCE_NORMAL_SWF_F2, ou TM_LFR_SCIENCE_NORMAL_SWF_F3.</p>
<p>En utilisant le champ PA_LFR_ACQUISITION_TIME:<br />-exp=300s: sur 2 périodes, on mesure res=300.00390625s<br />-exp=16: sur 61 périodes, on mesure res=16.00390625s</p>
<p>L'écart est satisfaisant; mais ce talon est toujours rigoureusement identique. Il pourrait y avoir un pb de principe à améliorer.<br />Notons que sur TM_LFR_SCIENCE_NORMAL_CWF_F3, on attend nom=168.0s. PA_LFR_ACQUISITION_TIME nous mène à 168.0s exactement.</p>
<p><ins>Contexte:</ins><br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.2 (variante sur carte finale) = r104</p>
<p>Brique Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE associé(s) = SVS-0029.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>