INSTRU: Issues
https://hephaistos.lpp.polytechnique.fr/redmine/
https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?1508097601
2023-01-19T10:26:55Z
Redmine
Redmine
LFR-FSW - Bug #4012 (Closed): TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/4012
2023-01-19T10:26:55Z
Veronique bouzid
<p>Dans le test /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0086/load_kcoeff_with_dump_v3-3.py</p>
<p>l'envoi d'un TC_LFR_LOAD_KCOEFFICIENTS avec KCOEFF_FREQ = 0, KCOEFF_1 = 1065353216 à KCOEFF_32 = 1065353216<br /> ne doit pas modifier les KCOEFF contenus dans la TM_LFR_KCOEFFICIENTS_DUMP.</p>
<p>Extrait</p>
<p><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=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000d233f, 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=26, <strong>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, SY_LFR_KCOEFF_9=1065353216, SY_LFR_KCOEFF_10=1065353216, SY_LFR_KCOEFF_11=1065353216, SY_LFR_KCOEFF_12=1065353216, SY_LFR_KCOEFF_13=1065353216, SY_LFR_KCOEFF_14=1065353216, SY_LFR_KCOEFF_15=1065353216, SY_LFR_KCOEFF_16=1065353216, SY_LFR_KCOEFF_17=1065353216, SY_LFR_KCOEFF_18=1065353216, SY_LFR_KCOEFF_19=1065353216, SY_LFR_KCOEFF_20=1065353216, SY_LFR_KCOEFF_21=1065353216, SY_LFR_KCOEFF_22=1065353216, SY_LFR_KCOEFF_23=1065353216, SY_LFR_KCOEFF_24=1065353216, SY_LFR_KCOEFF_25=1065353216, SY_LFR_KCOEFF_26=1065353216, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p>On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur modifiée par la TC_LFR_LOAD_KCOEFFICIENTS_alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).</p>
<p><ins>Ici les valeurs de référence récupérées au boot</ins></p>
<p><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=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, 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=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1050859893, SY_LFR_KCOEFF_2=1051774863, SY_LFR_KCOEFF_3=3199048410, SY_LFR_KCOEFF_4=3199675526, SY_LFR_KCOEFF_5=1048105208, SY_LFR_KCOEFF_6=1049731468, SY_LFR_KCOEFF_7=3199884855, SY_LFR_KCOEFF_8=3201093691, SY_LFR_KCOEFF_9=1002946415, SY_LFR_KCOEFF_10=993270132, SY_LFR_KCOEFF_11=1052396741, SY_LFR_KCOEFF_12=1051678457, SY_LFR_KCOEFF_13=3193633745, SY_LFR_KCOEFF_14=3195990147, SY_LFR_KCOEFF_15=3202344225, SY_LFR_KCOEFF_16=3204016481, SY_LFR_KCOEFF_17=3191761623, SY_LFR_KCOEFF_18=3194781000, SY_LFR_KCOEFF_19=0, SY_LFR_KCOEFF_20=2147483648, SY_LFR_KCOEFF_21=3164388996, SY_LFR_KCOEFF_22=3169957665, SY_LFR_KCOEFF_23=3164388996, SY_LFR_KCOEFF_24=3169957665, SY_LFR_KCOEFF_25=3156000388, SY_LFR_KCOEFF_26=3161569057, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p><strong>QUESTION<br />----------------<br />Est ce un bug ou bien le comportement attendu?</strong></p>
<p>Contexte du test<br />----------------------<br />FSW 3.3.0.11 et 3.3.0.12<br />VHDL 1.1.91<br />EM2 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p>
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 #981 (Closed): TC_LFR_LOAD_FILTER_PAR not acknowledged
https://hephaistos.lpp.polytechnique.fr/redmine/issues/981
2017-03-16T09:19:03Z
Veronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3++/set_load_filter_par.py.<br />L'envoi d une TC_LFR_LOAD_FILTER_PAR n est pas acquittée</p>
<p>09:56:29.206898,/home/validation/SCRIPT/R3++/set_load_filter_par.py<br />09:56:31.208759,PROXY LOAD is True<br />09:56:45.225339, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:56:50.226504, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:02.227914, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:07.228961, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:12.229741,End(/home/validation/SCRIPT/R3++/set_load_filter_par.py)</p>
<p>Les fichiers de données (2017_03_16-09_57_12*) sont rangés dans /home/validation/data/R3++/3.2.0.3/1.1.91/TEST-UNITAIRES/set_load_filter_par.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.3<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 #867 (Closed): Fonction setFBinMask: Calcul masque erroné
https://hephaistos.lpp.polytechnique.fr/redmine/issues/867
2016-12-29T11:44:23Z
Veronique bouzid
<p>J ai testé la fonction serFBinMask avec les parametres décrits ci-dessous<br />setFBinMask( fbins_mask, rw_f, deltaFreq, flag );</p>
<p>rw_f = 96.0<br />deltaFreq= 96.0</p>
<p>flag=1</p>
<p>Voila la trace du calcul</p>
<p>--> on trouve 3 bins à masquer 0,1,2<br /><strong>Channel = 0 and Freq = 96.000000</strong><br />binBelow = 1 and binAbove = 1<br />closestBin = 1<br /><strong>bin0 = 0 and bin1= 1 and bin2= 2</strong></p>
<p><ins>le premier masque calculé pour le bin 0</ins><br /> Byte Range is 15 and previous mask is 0xff (condition initiale)<br /> Byte Range is 15 and mask is 0xfe le maque calculé<br />au final<br /> <strong>Byte Range is 15 and current mask is 0xfe</strong></p>
<p><ins>le masque calculé pour le bin 1</ins><br /> Byte Range is 15 and previous mask is 0xfe<br /> Byte Range is 15 and mask is 0xfc le masque calculé<br /> <strong>Byte Range is 15 and current mask is 0xfc</strong></p>
<p>l+e masque calculé pour le bin 2+<br /> Byte Range is 15 and previous mask is 0xfc<br /> Byte Range is 15 and mask is 0xf8 le masque calculé<br /> Byte Range is 15 and current mask is 0xf8</p>
<p>et ensuite le tour en plus lié au k=3<br /> Byte Range is 15 and previous mask is 0xf8<br /> Byte Range is 15 and mask is 0xf8<br /> Byte Range is 15 and current mask is 0xf8</p>
<p>On obtient donc pour rw_f=96 hz et le channel 0, le masque suivant<br />Byte Range is 15 and current mask is 0xf8 ce qui signifie que les 3</p>
<p>Hors le tableau des frequences à F0 est le suivant <br />F0 <br />[ <strong>96 192</strong> 288 384 480 576 672 768<br /> 864 960 1056 1152 1248 1344 1440 1536<br /> 1632 1728 1824 1920 2016 2112 2208 2304<br /> 2400 2496 2592 2688 2784 2880 2976 3072<br /> 3168 3264 3360 3456 3552 3648 3744 3840<br /> 3936 4032 4128 4224 4320 4416 4512 4608<br /> 4704 4800 4896 4992 5088 5184 5280 5376<br /> 5472 5568 5664 5760 5856 5952 6048 6144<br /> 6240 6336 6432 6528 6624 6720 6816 6912<br /> 7008 7104 7200 7296 7392 7488 7584 7680<br /> 7776 7872 7968 8064 8160 8256 8352 8448<br /> 8544 8640 8736 8832 8928 9024 9120 9216<br /> 9312 9408 9504 9600 9696 9792 9888 9984<br /> 10080 10176 10272 10368 10464 10560 10656 10752<br /> 10848 10944 11040 11136 11232 11328 11424 11520<br /> 11616 11712 11808 11904 12000 12096 12192 12288]</p>
<p>et donc on devrait obtenir comme <strong>masque 0xfc</strong> puisque que 96 et 192 doivent etre masquées.</p>
<p>Je rappelle que la fréquence 0 n est pas à considérer comme indiqué dans le REQ-RPW-LFR-2407 du document RPW-MEB-LFR-00003 (Technical specifications)</p>
LFR-FSW - Bug #865 (Closed): Fonction setFBinMask erronée
https://hephaistos.lpp.polytechnique.fr/redmine/issues/865
2016-12-29T10:56:07Z
Veronique bouzid
<p>Pour avancer sur l'analyse du bug <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: Mauvais BIN filtrée suite à reception d'un UPDATE_INFO avec les fréquences RW : décalage de 1 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/864">#864</a> , je me suis permise de récuperer ta fonction setFBinMask et de la tester unitairement.</p>
<p>1- Cette boucle est erronée , la derniere valeur de k doit etre 2 et non 3<br /> for (k = 0; k <= 3; k++)
{<br /> bin = binToRemove[k];</p>
<p>--> la declaration du tableau est int binToRemove[ 3 ];<br />Si on a 3 bins à enlever tu vas superposer 4 masques.</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 #657 (Closed): HK_LFR_xE_CNT doesn't manage the wrap of 8bits counter error
https://hephaistos.lpp.polytechnique.fr/redmine/issues/657
2016-03-09T14:28:44Z
Veronique bouzid
<p>En Analysant le passage à zero des compteurs d'erreurs suivants (HK_LFR_TIMECODE_MISSING et HK_LFR_TIME_NOT_SYNCHRO, j observe bien le passage de 255 vers 0<br />pour les compteurs d'erreur codés sur 8 bits mais l'effet non attendu est que les compteurs HK_LFR_xE_CNT qui eux sont codés sur 16 bits ne sont plus bons car<br />ils representent la somme des erreurs liées à une criticité et donc le fait qu'un compteur passe à 0 diminue la valeur du ce compteur HK_LFR_xE_CNT<br />Voici un extrait du fichier Detail.txt</p>
<p>15:54:46.122923, TM_LFR_HK, TIME=0x000000ff81da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=509,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: NOT_SYNCHRO = 25, HK_LFR_LAST_ER_TIME=0x8000013bd189, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=255</strong>, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254,</strong> HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>15:54:47.122944, TM_LFR_HK, TIME=0x0000010081da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=254,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x000001003270, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=0,</strong> HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254</strong>, HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>Ceci est donc valable pour n'importe quel compteur codé sur 8 bits et utilisé dans une somme.</p>
<p>Les fichiers (2016_02_25-16_00_04-) sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0078/not_synchro.<br />Probleme remonté en lancant verif_fields sur le fichier Detail.txt.<br />Le fichier sss_cp_eqs_050.txt met en evidence les observations et permet de valider les passages à zero des compteurs :</p>
<p>15:54:47.122944, TM_LFR_HK<br />HK_LFR_LE_CNT: res=254; exp>=509 HK_LFR_TIMECODE_MISSING: res=0; exp>=255</p>
<p>15:55:49.123074, TM_LFR_HK<br />HK_LFR_DPU_SPW_TICK_OUT_CNT: res=0; exp>=255 HK_LFR_DPU_SPW_LAST_TIMC: res=0; exp>=63</p>
<p>15:56:50.123381, TM_LFR_HK<br />HK_LFR_LE_CNT: res=1; exp>=256 HK_LFR_TIME_NOT_SYNCHRO: res=0; exp>=255</p>
<p>Le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0078/update_time_not synchro_cnt_wrap.py.</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>
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>