INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012017-10-11T09:09:58ZRedmine
Redmine LFR-FSW - Bug #2134 (Stalled): Emission d'une raie à 96Hz par LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/21342017-10-11T09:09:58ZAlexis Jeandet
<p>Pendant les tests EMC, il a été mesuré une raie à 96Hz émise par LFR.<br />Après quelques investigations, ça s'explique par le fait que la consomation du FPGA entre le moment ou le CPU est en POWERDOWN et le moment ou il travaille est assez différente. De plus 96Hz correspond à la fréquence des interruptions pour les ASM à F0.<br />Une première tentative de mitigation en ajoutant une tache qui consomme du CPU en background a permis de baisser les niveaux d'émission mais c'est pas encore suffisant.<br />Il faut essayer de monter encore un peu la conso dans cette tache idle en utilisant la FPU par exemple.</p>
<ul>
<li><a href="https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/INSTRUMENTATION/USERS/JEANDET/LFR_FSW/changeset/fc82b08705ba9931880e4e57a76b1bb1ffa1e28e" class="external">Commit actuel</a></li>
<li><a href="https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/INSTRUMENTATION/USERS/JEANDET/SOLO_LFR_Notebooks/files/ea8683773e3816b28b499a7520bdfde53353a82a/LFR_CPU_POWERDOWN_EFFECT/LFR_CPU_POWERDOWN_EFFECT.ipynb" class="external">Analyse de l'effet du powerdown</a></li>
</ul> LFR-FSW - Bug #1029 (Stalled): La tâche AVGV semble s'arrêter lorsque l'on repasse en STDBY sur l...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10292017-03-27T14:15:21Zbruno katra
<p>La courbe ci-dessous montre les moyennes dans les HK avec un signal de 0.1Hz sur V et 5Hz sur E1 -3/3V en STANDBY puis passage en NORMAL pendant 10s et repassage en STANDBY (on voit d'ailleurs le bug <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 have amazing values when a TC_LFR_ENTER_MODE is... (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/955">#955</a> de Véro).</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2192/FLOWCHART01.png" alt="" /></p>
<p>Ceci est confirmé en regardant les valeurs dans les HK :<br />[LFR@pc-solar1 3.2.0.9]$ more hk<br /> V E1 E2<br /> 431 434 379 > STDBY<br /> 432 433 380>.....<br /> 430 433 380<br /> 430 433 380<br /> 432 434 379<br /> 431 434 379<br /> 430 435 380<br /> 431 434 380<br /> 431 434 380<br /> 430 434 380<br /> 432 433 379<br /> 431 436 380<br /> 431 434 380 <br /> 8279 1271 381 > NORMAL<br /> 22638 418 377<br /> 27125 409 376<br /> 21361 411 377<br /> 7575 411 377<br /> -8947 410 378<br /> -21935 410 378<br /> -26425 410 378<br /> -20669 410 377<br /> -6895 410 377<br /> 9642 410 378<br /> 22631 410 377> STDBY<br /> 540 415 338 <br /> 433 435 377<br /> 430 434 379<br /> 432 434 379<br /> 430 435 379</p>
<p>SSS-CP-EQS-526 ne stipule pas que la moyenne n'est faite qu'en mode SCIENCE. Nous avions compris que le moyennage est tout le temps actif (y compris en BURST et STANDBY où il n'y a pas de produits F3)</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/8972017-01-13T16:00:08ZWilliam Recartwilliam.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 #809 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_Parenthèses Severity is Mediumhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8092016-10-19T12:42:41ZWilliam Recartwilliam.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 #806 (Closed): Analyse Logiscope LFR_3.1.0.4 : Tr_ParenArg Severity is Highhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8062016-10-19T12:25:38ZWilliam Recartwilliam.recart@lpp.polytechnique.fr
<p>Rappel de la règle :<br />Tr_ParenArg<br />Definition:<br />-----------<br />Each occurrence of the macro parameters shall be enclosed in parenthesis <br />(or brackets) inside the macro definition.</p>
<p>Example:<br />--------</p>
<p>// do not write<br />#define GET_NAME(obj,ind) obj->name[ind]</p>
<p>// write<br />#define GET_NAME(obj,ind) (obj)->name[ind]</p>
<p>La règle n'est pas respectée dans 6 cas d'après Logiscope:<br />Fichier fsw_params.h : lignes 238, 239, 248, 249, 258, 259</p> 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 #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>