INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-01-30T15:34:47ZRedmine
Redmine LFR-FSW - Bug #4021 (Closed): FSW 3.3.0.14 : Valeurs moyennage potentiel s/c dans HK dupliquées e...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40212023-01-30T15:34:47Zbruno katra
<p>Dans FSW 3.3.0.14 : le moyennage dans les HK de E1 et E2 est identique alors que des signaux différents sont appliqués. En fait peu importe ce que l'on met comme signal sur E1 ses valeurs sont identiques à celle de E2. Si on change le signal sur E2, E1 change aussi pour être =E2.</p>
<p>Dans la capture en PJ (HKmeaning3.3.0.14) on injecte des signaux différents sur E1 et sur E2 et on voit que la réponse est la même dans les HK.</p> LFR-FSW - Bug #4020 (Closed): FSW 3.3.0.13 crashe avec certaines combinaisons de paramètres pour ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40202023-01-28T17:14:53Zbruno katra
<p>J'ai testé 29 combinaisons de paramètres pour PAS_FILTER plusieurs fois pour essayer de déterminer un critère de reproductibilité.</p>
<p>Les paramètres PAS par défaut sont pour rappel :<br />sy_lfr_pas_filter_modulus = 4<br />sy_lfr_pas_filter_tbad = 1<br />sy_lfr_pas_filter_offset = 0<br />sy_lfr_pas_filter_shift = 0.5</p>
<p><ins>Pour certaines combinaisons :</ins> * le FSW crashe (plus de HK) dès que des ASM doivent être produites pour être envoyées*</p>
<p><ins>Voici les résultats :</ins></p>
<ul>
<li>PARAMETRES PAS PAR DEFAUT : OK, pas de carsh</li>
<li>TOUTES LES COMBINAISONS AVEC sy_lfr_pas_filter_modulus = sy_lfr_pas_filter_tbad = 4 : NOK, crashe systématiquement dès que les ASM doivent être envoyées (testé avec ASM à 4/8/12/16s)</li>
<li>COMBINAISONS AVEC sy_lfr_pas_filter_modulus = 8 et sy_lfr_pas_filter_tbad = 4 : POK, crashe des fois mais pas tout le temps, en fonction des paramètres précédemment entrés j'ai l'impression, reproductibilité aléatoire mais toujours quand les ASM doivent être envoyées (testé avec ASM à 4/8/16s)</li>
<li>TOUTES LES AUTRES COMBINAISONS testées : OK, pas de crash</li>
</ul>
<ul>
<li>Les crashs ne se produisent que si le filtrage est activé (sy_lfr_pas_filter_enabled = 1 ) = si on envoie les combinaisons qui font crasher mais sans activer le filtrage : pas de crash</li>
</ul>
<ul>
<li>Test refait en 3.2.0.24 : pas de crash</li>
</ul> 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/40122023-01-19T10:26:55ZVeronique 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 #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 #984 (Closed): FFT retirée alors que en dehors du TBAD https://hephaistos.lpp.polytechnique.fr/redmine/issues/9842017-03-16T15:26:31Zbruno katra
<p>Injection du signal suivant synchronisé avec le modulus du filtre PAS (enabled) : <br />première seconde : signal à 16Hz<br />3 secondes suivantes : 100Hz</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2140/signal01.png" alt="" /></p>
<p>Avec les paramètres PAS suivants on obtient le comportement attendu : la première seconde (16hz ) est bien filtrée<br />TBAD = 1.0<br />SHIFT = 0<br />OFFSET = 0<br />MODULUS = 0</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2142/asmf2-01.png" alt="" /></p>
<p>On met ensuite le TBAD = 0.0, on obtient le comportement attendu : on voit bien les 2 pics à 16Hz et 100Hz :</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2143/asmf2-02.png" alt="" /></p>
<p>Par contre après, on met un OFFSET = 1 en laissant le TBAD = 0.0 : le pic de 16 Hz est filtré alors qu'il ne devrait pas :</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2144/asmf2-03.png" alt="" /></p>
<p><strong>NB1</strong> : <br />on peut observer le même comportement avec une conf analogue : OFFSET =0 / SHIFT =1.0 / TBAD = 0.0</p>
<p><strong>NB2</strong> :</p>
<p>Si l'on met un TBAD = 1.0 avec les conf citées on voit bien le pic de 100 Hz qui diminue comme attendu mais le pic de 16Hz reste filtré.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.2<br />VHDL 1.1.91<br />EM1 AVEC Timegen<br />StarDundee<br />Analog discovery</p> LFR-FSW - Bug #182 (Closed): [JIRA] (RPWMEB-283) The content of the PA_LFR_ACQUISITION_TIME ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1822014-07-09T08:39:49ZVeronique bouzid
<p>Suite à la remontée par Philippe Plasson de l incident RPWMEB-283</p>
<p>J ai ecrit un test pour reproduire le bug.Ce script se nomme <strong>my_timeissue_normal.py</strong>. Il se trouve sous /home/validation.Il est en piece jointe.</p>
<p>J'ai envoyé un <strong>UPDATE_TIME</strong> avec comme temps de réference <strong>CP_RPW_TIME=0x1b45fd970000</strong><br />qui correspond au 1er juillet 2014 vers 23h10 . J ai mis le temps indiqué par Philippe sans vérifier que cela correspondait bien au 1er juillet 2014.<br />Je leur fais confiance.</p>
<p>Je vois bien la mise à l heure de LFR apres reception du time code<br />09:30:22.591245, TM_LFR_HK,TIME=0x8000000346da</p>
<p><strong>09:30:23.591236, TM_LFR_HK,TIME=0x1b45fd976093</strong></p>
<p>la premiere données scientifique qui arrive<br />09:30:23.991365, TM_LFR_SCIENCE_NORMAL_BP1_F0,*TIME=0x1b44fd97a7e4,PA_LFR_ACQUISITION_TIME=0x1b44fd97a7e4*</p>
<p><strong>et la BINGO, on voit 0x1b44 au lieu de 0x1b45</strong>*
*<br />idem pour toutes le TM</p>
<p>09:35:26.392595, TM_LFR_SCIENCE_NORMAL_SWF_F0, TIME=0x9b44febfa146,PA_LFR_ACQUISITION_TIME=0x9b44febfa146<br />09:35:28.59267, TM_LFR_SCIENCE_NORMAL_SWF_F1,TIME=0x9b44febf6c3e,PA_LFR_ACQUISITION_TIME=0x9b44febf6c3e</p>
<p>--------------------------------------------------------------------------------------<br />Contexte:</p>
<p>SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: 1.1.23<br />Soft: 2.0.0.0 <br />Brique Star-Dundee S/N 46120065.</p>
<p>script: /home/validation/my_timeissue.py</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue3_rev0</p> LFR-FSW - Bug #169 (Closed): En SBM1, l'arrivée d'un SWF fait planter le soft de vol.https://hephaistos.lpp.polytechnique.fr/redmine/issues/1692014-06-12T10:13:28Zbruno katra
<p>Le test SVS-0019 plante systématiquement le soft de vol au même moment (compteur HK = 543).<br />L'analyse du test de Gérald montre que cela se passe lorsqu'on est en SBM1.</p>
<p>Véro et Bruno sont en train de chercher plus précisément le contexte des paramètres qui provoque ce bug et sa reproductibilité.</p>
<p>------------------------------------------------<br />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.1.16<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.8 (variante sur carte finale)</p>
<p>TEST CASE : SVS-0019</p> LFR-FSW - Bug #167 (Closed): TC_LFR_LOAD_NORMAL_PAR avec SY_LFR_N_BP_P0 = 0 fait planter le soft ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1672014-06-11T14:41:44Zbruno katra
<p>L'envoi de TC_LFR_LOAD_NORMAL_PAR avec SY_LFR_N_BP_P0 = 0 devrait renvoyé TM_LFR_TC_EXE_ERROR_INCONSISTENT (vf bug <a class="issue tracker-1 status-5 priority-5 priority-highest closed" title="Bug: TC_LFR_LOAD_NORMAL_PAR: SY_LFR_N_ASM_P, SY_LFR_N_BP_P0 et , SY_LFR_N_BP_P1 = 0 acceptés (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/85">#85</a>) mais au lieu de ça le soft freeze :<br />- plus d'ack<br />- plus de HK</p>
<p>La vidéo jointe à cette issue montre ce qui se passe.</p>
<p>-------------------------------------------<br />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.1.16<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.8 (variante sur carte finale)</p>
<p>TEST CASE : script SY_LFR_N_BP_P0_failure.py dans SVS-0008</p> LFR-FSW - Bug #108 (Closed): Champs TIME et ACQUISITION_TIME différents dans les TM_LFR_SCIENCE_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/1082014-03-31T14:59:04Zbruno katra
<p>Dans les TM science, les 2 champs TIME ont des valeurs différentes alors que ceux-ci devraient avoir la même valeur ACQUISITION_TIME qui est le temps du premier échantillon du paquet (SSS-CP-EQS-410).</p>
<p>15:31:35.368491, TM_LFR_SCIENCE_BURST_CWF_F2, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=4051, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, <strong>TIME=0x800001fd7f1b</strong>, PA_LFR_SID_PKT: SC_B_CWF_F2 = 2, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, SPARE: 0x0, <strong>PA_LFR_ACQUISITION_TIME=0x800001f30000</strong>, PA_LFR_CWF_BLK_NR=336</p>
<p>Contexte:<br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.3 (variante sur carte finale) = r109</p>
<p>Brique Star-Dundee S/N illisible.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2<br />RPW-SYS---ICD-00067-LES_Issue2_Rev2_RPW_IDB_Parameter_Definition</p> LFR-FSW - Bug #104 (Closed): SY_LFR_FPGA_VERSION_N3 de TM_LFR_HK erronéhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1042014-03-28T13:17:19ZGerald Saule
<p>TM_LFR_HK, SY_LFR_FPGA_VERSION_N3=255 est une coquille.<br />On attend SY_LFR_FPGA_VERSION_N3=7.</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.1.7<br />Soft: 1.0.0.4 (variante sur carte finale)<br />Brique Star-Dundee S/N <blank>.</p>
<p>TEST CASE = 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 #97 (Rejected): TM_LFR_HK: sauts de HK_LFR_DPU_SPW_PKT_SENT_CNThttps://hephaistos.lpp.polytechnique.fr/redmine/issues/972014-03-19T12:04:35ZGerald Saule
<p>Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.<br />Les traces obtenues sont:</p>
<blockquote>
<p>18:38:27.989082, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=1728, HK_LFR_MODE: STANDBY = 0</p>
<p>DECONNECTION/RECONNECTION</p>
<p>18:38:30.59011, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=*4003*; exp=1729 , HK_LFR_MODE: STANDBY = 0</p>
</blockquote>
<p>Le pb porte sur le saut inaproprié de la valeur de HK_LFR_DPU_SPW_PKT_SENT_CNT.<br />Notons que la déconnexion se traduit ici par une absence de TM pendant 2.6s, ce qui laisse présentir que le FSW a identifié une perte du lien confirmée pendant SY_LFR_DPU_CONNECT_TIMEOUT (=1000ms); une mise en oeuvre des SSS-CP-EQS-153/154/155 étant prévisible.</p>
<p>Ce test montre aussi d'autres irrégulariés de HK_LFR_DPU_SPW_PKT_SENT_CNT: davantage compréhensibles, elles sont tracées par l'issue "TM_LFR_HK: HK_LFR_DPU_SPW_PKT_SENT_CNT périmé".</p>
<p><ins>Contexte:</ins></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.15<br />Soft: 1.0.0.1 (variante sur carte finale)<br />Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0061</p>
<p>RPW-SYS-IDB-00067-LES_Issue1_Rev8<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> VHDLib - Bug #96 (Rejected): DMA latency to access External memoryhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/962014-03-18T09:18:41ZJean-Christophe Pellion
<p>1- Verify than there is too waitstate access during a Memory Burst Access<br />2- Try others configurations to limit this latency ...</p> LFR-FSW - Bug #85 (Closed): TC_LFR_LOAD_NORMAL_PAR: SY_LFR_N_ASM_P, SY_LFR_N_BP_P0 et , SY_LFR_N_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/852014-03-12T09:35:44ZGerald Saule
<p>Le LFR FSW accepte des périodes nulles. Ce n'est pas interdit par l'ICD; néanmoins, le comportement associé est indéfini.</p>
<blockquote>
<p>09:51:24.915628, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), <strong>SY_LFR_N_ASM_P = 0(s)</strong>, SY_LFR_N_BP_P0 = 4(s), SY_LFR_N_BP_P1 = 20(s)<br />09:51:24.918065, TM_LFR_TC_EXE_SUCCESS</p>
<p>09:51:25.116246, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 4(s), <strong>SY_LFR_N_BP_P0 = 0(s)</strong>, SY_LFR_N_BP_P1 = 20(s)<br />09:51:25.119052, TM_LFR_TC_EXE_SUCCESS</p>
<p>09:51:25.320007, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 4(s), SY_LFR_N_BP_P0 = 4(s), <strong>SY_LFR_N_BP_P1 = 0(s)</strong><br />09:51:25.321911, TM_LFR_TC_EXE_SUCCESS</p>
</blockquote>
<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 #65 (Closed): TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/652014-02-24T14:13:06ZGerald Saule
<p>Cette issue reprend l'issue Bug <a class="issue tracker-4 status-5 priority-3 priority-high3 closed" title="Task: Delivery 3.1.0.5 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/905">#905</a> (TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1).</p>
<p>Pour TC_LFR_LOAD_NORMAL_PAR, les champs SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1 ne sont pas controlés.<br />La valeur 0 devrait être un moyen simple d'obtenir un rejet (il s'agit de périodes).<br />LFR retourne TM_LFR_TC_EXE_SUCCESS.</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_0008</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>