INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012016-10-19T12:24:16ZRedmine
Redmine LFR-FSW - Bug #805 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_OrdreChoix Severity is Highhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8052016-10-19T12:24:16ZWilliam Recartwilliam.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_OrdreChoix<br />Definition:<br />-----------<br />A default case is mandatory within a switch in order to cover unexpected cases.</p>
<p>Parameters:<br />----------<br />The character string "last", which, if used, specifies that the default case <br />has to be the last one.</p>
<p>La règle n'est pas respectée dans 3 cas d'après Logiscope:<br />Fichier fsw_processing.c : lignes 72, 130, 187</p> LFR-FSW - Bug #804 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_ModelFonction Severity is Highhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8042016-10-19T12:22:47ZWilliam Recartwilliam.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_ModelFonction<br />Definition:<br />-----------<br />Use inline functions instead of macro-functions.</p>
<p>Example:<br />--------</p>
<p>// write<br />inline char *GetName(aClass &object) {<br />return(object.name);<br />}</p>
<p>// do not write<br />#define GetName(s) ((s)->name)</p>
<p>La règle n'est pas respectée dans 120 cas d'après Logiscope:<br />Fichier fsw_params.h : lignes 237, 238, 239, 241, 242, 243, 247, 248, 249, 251, 252, 253, 257, 258, 259, 261, 262, 263</p> LFR-FSW - Bug #803 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_BoucleSortie Severity is Highhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8032016-10-19T12:21:22ZWilliam Recartwilliam.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_BoucleSortie<br />Definition:<br />-----------<br />Break and continue instructions are forbidden inside conditional expressions <br />in control statements ( for, do, while ).<br />Nevertheless, the break instruction is allowed in the block instruction <br />of the switch statement.</p>
<p>Parameters:<br />-----------</p>
<p>C++:
====<br />None.</p>
<p>JAVA:
=====<br />A string identifying the type of checking:</p>
<ul>
<li>"in_switch" (or no parameter) means that the break are allowed in switch <br />statements, break and continue are forbidden everywhere else,</li>
</ul>
<ul>
<li>"without_label" means that any break or continue without a label is allowed,</li>
</ul>
<ul>
<li>"with_label" means that any break and continue with a label is allowed,<br />break and continue without a label is forbidden everywhere.</li>
</ul>
<p>Justification:<br />--------------<br />Like a goto, these instructions break down code structure. Prohibiting them<br />in loops makes the code easier to understand.</p>
<p>La règle n'est pas respectée dans 3 cas d'après Logiscope:<br />Fichier fsw_misc.c : ligne 266<br />Fichier fsw_spacewire.c : ligne 518<br />Fichier wf_handler.c : ligne 832</p> LFR-FSW - Bug #802 (Closed): Analyse Logiscope LFR_3.1.0.4 : rule Tr_Accolades Severity is Highhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8022016-10-19T12:17:22ZWilliam Recartwilliam.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_Accolades<br />Definition:<br />-----------<br />Block statements shall always be used in control statements (if , for , while , do).</p>
<p>Justification:<br />--------------<br />Removes ambiguity about the scope of instructions and makes the code easier to read<br />and to modify.</p>
<p>Example:<br />--------</p>
<p>// do not write<br />if (x 0) return;<br />else <br />while (x > min) <br /> x--;</p>
<p>// write<br />if (x 0) {<br /> return;<br />} else {<br /> while (x > min) {<br /> x--;<br /> }<br />}</p>
<p>La règle n'est pas respectée dans 38 cas d'après Logiscope:<br />Fichier avf0_prc0.c : lignes 119, 132, 225, 234, 391, 396<br />Fichier avf1_prc1.c : lignes 120, 133, 226, 381<br />Fichier fsw_init.c : lignes 788, 792, 796<br />Fichier fsw_processing.c : ligne 565<br />Fichier fsw_processing.h : lignes 222, 227, 251, 256<br />Fichier fsw_spacewire.c : lignes 274, 278, 282, 286, 290, 294, 303, 975<br />Fichier lfr_cpu_usage_report.c : ligne 53<br />Fichier tc_acceptance.c : ligne 463<br />Fichier tc_handler.c : ligne 1585<br />Fichier tc_load_dump_parameters.c : lignes 1028, 1330, 1337<br />Fichier wf_handler.c : lignes 127, 199, 223, 248, 475, 1277</p> LFR-FSW - Bug #801 (Closed): Analyse Logiscope LFR_3.1.0.4 : Don_Initialisation_P2 Severity is Highhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8012016-10-19T12:13:09ZWilliam Recartwilliam.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 #796 (Closed): Analyse Logiscope LFR_3.1.0.4 : rule Don_Initialisation_P1 Severity ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/7962016-10-18T15:26:50ZWilliam Recartwilliam.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Don_Initialisation_P1:<br />Definition:<br />-----------<br />Global variables must be initialized when they are defined.</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. Initializing global variables <br />when they are declared ensures that they are initialized before being used.</p>
<p>La règle n'est pas respectée dans 120 cas d'après Logiscope:<br />Fichier avf0_prc0.c : lignes 13, 17, 18, 20, 21, 23, 24, 25, 27, 28, 29, 31, 32<br />Fichier avf1_prc1.c : lignes 12, 18, 19, 21, 22, 24, 25, 26, 28, 29, 30, 32, 33<br />Fichier avf2_prc2.c : lignes 12, 18, 20, 21, 23, 24, 26, 27, 29<br />Fichier fsw_globals.c : lignes 26, 27, 28, 29, 30, 33, 34, 43, 44, 45, 46, 52, 53, 54, 63, 64, 65, 68, 69, 71, 72, 73, 74, 75, 77, 78, 79, 80, 81, 82, 85, 86, 87, 88, 89, 90, 91, 92, 95, 97<br />Fichier fsw_misc.h : lignes 29, 30<br />Fichier fsw_processing.c : lignes 14, 15, 16, 17, 28, 29, 30, 31, 32, 33, 34, 35, 36<br />Fichier fsw_processing.h : ligne 105<br />Fichier fsw_spacewire.c : lignes 16, 17, 21, 22, 23<br />Fichier tc_acceptance.c : ligne 13<br />Fichier tc_load_dump_parameters.c : lignes 17, 18, 19, 20<br />Fichier wf_handler.c : lignes 15, 16, 17, 19, 20, 21, 22, 24, 25, 26, 27, 29, 30, 31, 32, 41, 42, 43, 44</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/3972015-04-23T10:25:38ZVeronique 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> LFR-FSW - Bug #114 (Closed): TM_LFR_TC_EXE_ERROR inopportunhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1142014-04-03T12:00:34ZGerald Saule
<p>LFR émet TM_LFR_TC_EXE_ERROR sans justification.<br />Au démarrage, la commande d'une transition vers STANDBY est rejetée (ce qui est normal, étant déjà en STANDBY). Il ne doit pas y avoir de second acquittement par un TM_LFR_TC_EXE_ERROR.</p>
<blockquote>
<p>11:22:35.48082, TC_LFR_ENTER_MODE (PACKET_SEQUENCE_CONTROL=*0xdc85*), CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000000000<br />11:22:36.716753, TM_LFR_HK<br />11:22:36.71717, TM_LFR_HK<br />11:22:36.738436, TM_LFR_TC_EXE_NOT_EXECUTABLE, 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=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=19, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000211e0, PA_RPW_TC_FAILURE_CODE: TC_NOT_EXE = 42000, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=*0xdc85*, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=41, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0<br />11:22:36.73871, <strong>TM_LFR_TC_EXE_ERROR</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=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=17, 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=0x800000021227, PA_RPW_TC_FAILURE_CODE: FAIL_DETECTED = 42003, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=*0xdc85*, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=41</p>
</blockquote>
<p><ins>Contexte:</ins><br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.9<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.5 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0013<br />Req = s.o.</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #89 (Closed): Attente de la première TM_LFR_SCIENCE_BURST_CWF_F2/TM_LFR_SCIENCE_NOR...https://hephaistos.lpp.polytechnique.fr/redmine/issues/892014-03-13T15:44:13ZGerald Saule
<p>A partir du passage en mode BURST, la première TM_LFR_SCIENCE_BURST_CWF_F2 est envoyée 13s plus tard.<br />C'est inatendu, car on attend une période entre ces salves de TM_LFR_SCIENCE_BURST_CWF_F2 de 10.5s (1688/F2).<br />Cela ne pose pas de pb fonctionnel; ainsi, la "Priority" de cette issue est estimée à Low (en mode BURST établi, la période est correcte).</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)</p>
<p>Vhdl: mini-lfr_0.0.0.15</p>
<p>Soft: 1.0.0.2 (variante sur carte finale) = r104</p>
<p>Brique: Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0041</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #87 (Closed): Perte d'un TM_LFR_HKhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/872014-03-12T15:22:55ZGerald Saule
<p>Il s'agit d'un phénomène très rare (et donc difficilement reproductible).<br />Les outils de surveillance automatique (./lfrverif/common/verif_fields.py) permettent d'utiliser "sss-cp-eqs-050" qui met évidence cette issue.</p>
<p>On remarque que la perte d'un HK correspond à peu près avec le mécanismes d'acquittement suite au TC_LFR_ENTER_MODE.</p>
<blockquote>
<p>12:09:56.278367, TM_LFR_HK, <strong>SEQUENCE_CNT=2017</strong>, TIME=0x80000814b026, HK_LFR_MODE: NORMAL = 1, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=17, HK_LFR_REJ_TC_CNT=4, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=41, HK_LFR_LAST_EXE_TC_TIME=0x80000738a2d7, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=13, HK_LFR_LAST_REJ_TC_TIME=0x8000073769a2, HK_LFR_DPU_SPW_PKT_RCV_CNT=21, HK_LFR_DPU_SPW_PKT_SENT_CNT=3117<br />12:09:56.343328, TM_LFR_SCIENCE_NORMAL_SWF_F2<br />12:09:56.643295, TM_LFR_SCIENCE_NORMAL_SWF_F2<br />12:09:56.943474, TM_LFR_SCIENCE_NORMAL_SWF_F2<br />12:09:57.243305, TM_LFR_SCIENCE_NORMAL_SWF_F2<br />12:09:57.28402, TC_LFR_ENTER_MODE (CP_LFR_MODE=0)<br />12:09:57.301865, TM_LFR_TC_EXE_SUCCESS<br />12:09:58.278362, TM_LFR_HK, <strong>SEQUENCE_CNT=2019</strong>, TIME=0x80000816b027, HK_LFR_MODE: STANDBY = 0, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=18, HK_LFR_REJ_TC_CNT=4, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=41, HK_LFR_LAST_EXE_TC_TIME=0x80000815b671, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=13, HK_LFR_LAST_REJ_TC_TIME=0x8000073769a2, HK_LFR_DPU_SPW_PKT_RCV_CNT=22, HK_LFR_DPU_SPW_PKT_SENT_CNT=3124</p>
</blockquote>
<p>Ce pb étant très rare, et sans impact significatif, la 'Priority' est affectée à Low.</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> LFR-FSW - Bug #84 (Closed): Talon dans la période de génération des TM_LFR_SCIENCE_xhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/842014-03-11T18:10:22ZGerald 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> LFR-FSW - Bug #83 (Closed): Talon dans la période de génération des TM_LFR_SCIENCE_NORMAL_SWF_Fxhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/832014-03-11T18:08:04ZGerald 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 essai 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> LFR-FSW - Bug #82 (Closed): Pas de control sur SY_LFR_N_SWP_P de TC_LFR_LOAD_NORMAL_PARhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/822014-03-11T16:37:48ZGerald Saule
<p>D'après l'ICD, SY_LFR_N_SWP_P doit être inférieur ou égal à 65528.</p>
<p>Avec 0xffff, LFR devrait retourner un rejet. On a malheureusement un success:</p>
<blockquote>
<p>15:38:16.287476, TC_LFR_LOAD_NORMAL_PAR, /!\SY_LFR_N_SWP_P = 65535(s), SY_LFR_N_ASM_P = 65535(s), SY_LFR_N_BP_P0 = 255(s), SY_LFR_N_BP_P1 = 255(s),SY_LFR_N_CWF_LONG_F3 = 1<br />15:38:16.28993, TM_LFR_TC_EXE_SUCCESS<br />15:38:17.054305, TM_LFR_HK, HK_LFR_MODE: STANDBY = 0, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15<br />15:38:17.288114, TC_LFR_DUMP_PAR<br />15:38:17.290797, TM_LFR_PARAMETER_DUMP, SY_LFR_N_SWF_L=2048, /!\SY_LFR_N_SWF_P=65535(s), SY_LFR_N_ASM_P=65535(s), SY_LFR_N_BP_P0=255(s), SY_LFR_N_BP_P1=255(s), SY_LFR_N_CWF_LONG_F3=1<br />15:38:17.294221, TM_LFR_TC_EXE_SUCCESS</p>
</blockquote>
<p>Il peut s'agir d'un fonctionnement correct avec une modification à faire dans l'ICD.</p>
<p>Contexte:</p>
<p>LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f<br />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: Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0029</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #72 (Closed): Perte de périodicité sur ultime TM_LFR_SCIENCE_SBM2_CWF_F2https://hephaistos.lpp.polytechnique.fr/redmine/issues/722014-02-26T17:22:37ZGerald Saule
<p>Les TM_LFR_SCIENCE_SBM2_CWF_F2doivent être générées à la fréquence de 256.0Hz. Ainsi, les données étant bufferisées, on attend uns salve de 8 TM_LFR_SCIENCE_SBM2_CWF_F2 toutes les 10.5s.</p>
<p>On observe très précisement cette cadence (sur les 36 périodes précédentes), sauf dans le cas ci-dessous:</p>
<blockquote>
<p>17:18:53.066229, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c000a8<br />17:18:53.074801, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c150a8<br />17:18:53.078671, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c2a0a8<br />17:18:53.082048, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c3f0a8<br />17:18:53.085287, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c540a8<br />17:18:53.101314, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c690a8<br />17:18:53.105723, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c7e0a8<br />17:18:53.109579, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007c930a8<br />17:18:53.93814, TM_LFR_HK<br />17:18:54.938771, TM_LFR_HK<br />17:18:55.938731, TM_LFR_HK<br />17:18:56.938748, TM_LFR_HK<br />17:18:57.938755, TM_LFR_HK<br />17:18:58.938711, TM_LFR_HK<br />17:18:59.938724, TM_LFR_HK<br />17:19:00.53456, TM_LFR_SCIENCE_NORMAL_CWF_LONG_F3<br />17:19:00.939025, TM_LFR_HK<br />17:19:01.938561, TM_LFR_HK<br />17:19:02.93855, TM_LFR_HK<br />17:19:03.556298, TC_LFR_ENTER_MODE (CP_LFR_MODE=0), 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=7277, (PACKET_SEQUENCE_CONTROL=0xdc6d), PACKET_LENGTH=13, 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: ENTER_MODE = 41, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0, CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000000000, CRC = 0x65b1<br />17:19:03.566126, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007cfc0a8<br />17:19:03.574951, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007d110a8<br />17:19:03.579086, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007d260a8<br />17:19:03.585768, TM_LFR_SCIENCE_SBM2_CWF_F2, PA_LFR_ACQUISITION_TIME=0x800007d3b0a8<br />17:19:03.588339, TM_LFR_TC_EXE_SUCCESS, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xdc6d</p>
</blockquote>
<p>On mesure malheureusement un délai de 15.75s, ce qui est hors tolérance pour les outils automatisés (Python) de mesure de période.<br />Visiblement, le traitement du TC_LFR_ENTER_MODE provoque cette irrégularité.<br />Le fonctionnement en régime établi étant ok, je propose un niveau de priorité "Low".</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />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 />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.1 (variante sur carte finale)</p>
<p>TEST CASE = SVS_0019<br />Req: SSS-CP-FS-590</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #71 (Closed): Initialisation de SEQUENCE_CNT des TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/712014-02-26T15:30:45ZGerald Saule
<p>Suite au démarage (HW&SW), on obtient les traces:</p>
<blockquote>
<p>10:55:39.444599, TC_LFR_LOAD_COMMON_PAR, 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=2802, (PACKET_SEQUENCE_CONTROL=0xcaf2), PACKET_LENGTH=7, 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_COMMON_PARAMETERS = 11, SOURCE_ID: MISSION_TIMELINE = 110, SPARE = 0x0, SY_LFR_BW = 1, SY_LFR_SP0 = 0, SY_LFR_SP1 = 0, SY_LFR_R0 = 0, SY_LFR_R1 = 0, CRC = 0x818d</p>
<p>10:55:39.446617, TM_LFR_TC_EXE_SUCCESS, 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=0, (PACKET_SEQUENCE_CONTROL=0xc000), 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=0x800003adf1b9, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xcaf2</p>
</blockquote>
<p>Le champ SEQUENCE_CNT correspond à la valeur initiale incrémentée de 1, d'après la SSS.<br />L'initialisation étant à 0, n attend donc un première valeur à 1.</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />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 />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.1 (variante sur carte finale)</p>
<p>TEST CASE = SVS_0019<br />Req: SSS-CP-FS-590</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>