INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-02-01T08:14:05ZRedmine
Redmine LFR-FSW - Bug #4022 (Closed): Validation BP des modes SBM1 et SBM2https://hephaistos.lpp.polytechnique.fr/redmine/issues/40222023-02-01T08:14:05Zbruno katra
<p>Salut Bruno,</p>
<p>Je viens de de comparer les BP2 à F0 en SBM1 avec les ASM à F0 en NM, du moins les termes diagonaux (les AUTO). J'ai des résultats du même ordre (écart de plusieurs dizaines de %) donc pas aberrant. En fait je réalise que pour ce teste et être plus précis (comparer des signaux forts et non des niveaux de bruit), il faudrait avoir injecter dans la gamme de fréquence F0 et non F1. As-tu encore le temps de refaire ce test SBM1 en balayant les fréquence F0 ?</p>
<p>Et en fait même problème pour le test SBM2: il faudrait balayer les fréquences F1 et F0 ...</p>
<p>Désolé pour ce contre temps</p>
<p>Thomas</p> 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 #4018 (Closed): FSW 3.3.0.13 instrumenté pour mesure du SCRUBBING : le compteur res...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40182023-01-27T11:14:28Zbruno katra
<p>On utilise dans cette version spécifique du FSW la valeur HK de la version FPGA pour compter les cycles de scrubbing.</p>
<p>En FSW 3.3.0.13 : on voit bien la valeur à 0 au début comme attendu mais elle ne s'incrémente jamais, testé en STANDBY et NORMAL. Pour comparaison en 3.2.0.24 on s'oncrémentait de 1 toutes les 3s environ en STDBY.</p> LFR-FSW - Bug #4015 (Closed): HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteu...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40152023-01-24T11:00:35ZVeronique bouzid
<p>Le test SVS-0026 doit vérifier le requirement suivant<br />All the counters (error counter, packet counter, etc) managed by LFR FSW shall restart at 0 when tehy reached their maximun value.</p>
<p>Le script qui teste le compteur HK_LFR_DPU_SPW_RX_TOO_BIG envoie 257 Tc générant une erreur. Le compteur valide bien le requirement et on voit parfaitement le passage à zero.</p>
<p>Un autre compteur nommé HK_LFR_ME_CNT comptabilise les erreurs de type medium. HK_LFR_DPU_SPW_RX_TOO_BIG fait partie de ce type d erreur et donc on s'attend à la fin du test à obtenir<br />HK_LFR_ME_CNT=257. Ce n est pas le cas il manque 1.</p>
<p>Ici un extrait des valeurs de ces 2 compteurs (fichir verif_count.txt)<br />11:47:45.222921 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=0 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />11:47:46.242728 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:47.222395 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:48.223832 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:49.222892 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:50.223058 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=2 HK_LFR_DPU_SPW_RX_TOO_BIG=2<br />----</p>
<p>12:04:48.226406 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=255<br />12:04:49.225973 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0</strong><br />12:04:50.225914 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:51.226438 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:52.225955 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:53.225879 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:54.22646 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:55.225976 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:56.225969 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:57.22624 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:58.226003 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:59.226005 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:00.226468 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:01.226032 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1</strong></p>
<p>On voit la parfaite égalité des 2 compteurs excepté après le wrap de HK_LFR_DPU_SPW_RX_TOO_BIG.<br />Le script joué se nomme /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_rx_too_big_cnt_wrap.py et les fichiers de test sont dans<br />/home/validation/data/R3.3/3.3.0.11/1.1.91/SVS-0026/TESTS/check_rx_too_big_cnt_wrap</p>
<p>Contexte du test<br />---------------------<br />FSW 3.3.0.11<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />StarDundee</p>
<p><strong>ATTENTION<br />Il se peut que ce bug soit applicable également à la gestion du compteur d'erreur HK_LFR_LE_CNT.</strong></p> LFR-FSW - Bug #4013 (Closed): LFR en mode compilé pour les CPU_STATS crashe en SBM1https://hephaistos.lpp.polytechnique.fr/redmine/issues/40132023-01-19T10:39:16Zbruno katra
<p>Quand on execute FSW 3.3.0.12 compilé avec les CPU_STATS :<br />- passage en NORMAL puis STDBY : OK, sortie série avec STATS CPU<br />- passage en SBM1 : NOK, seulement les BP/ASM @F1 et @F0 sont produits, pas de produits F2 et le soft crash au bout de quelques secondes</p>
<p>Même tests refaits en 3.2.0.24 : OK</p> 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 #4007 (Closed): Le FSW crashe pendant l'envoi massif de TC_LFR_LOAD_KCOEFFhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40072022-12-27T14:39:57Zbruno katra
<p>FSW 3.3.0.11<br />TEST SVS-0022</p>
<p>Hello</p>
<p>Je viens de relancer une troisième fois le test. Cette fois aucun plantage. Ce test est un test de charge (envoi de cdes) et le mode choisi est le SBM1.</p>
<p>J'avais fait 2 captures d'écran du LFR GSE que je documenterai dans le Redmine. Les 1000 cdes TC_LFR_LOAD_KCOEFF avaient été rejetées car le mode LFR actif etait SBM1 et non standby. Le soft a bien remonté 1000 erreurs (hk_lfr_rej_tc_cnt = 1000) , ce qui est cohérent.</p>
<p>Le plantage a eu lieu pendant l'envoi des 1000 cdes TC_LFR_DUMP_KCOEFFICIENTS, le premier indique la 268eme TC et le deuxieme indique 266eme TC.</p>
<p>Je referai un test à la rentrée.</p>
<p>@AlexisJ tu peux mettre ton cerveau au repos.</p>
<p>Bonne soirée.</p>
<p>Véronique<br />Le 21/12/2022 à 13:27, Alexis Jeandet a écrit :</p>
<blockquote>
<p>Ok, c'est presque normal, au moins je sais où regarder en parallèle si jamais je vois quelque chose de flagrant. Sinon est-ce que ça pourrait être côté gse?</p>
<p>Le 21 décembre 2022 12:59:13 GMT+01:00, "Véronique Bouzid" <<a class="email" href="mailto:veronique.bouzid@lpp.polytechnique.fr">veronique.bouzid@lpp.polytechnique.fr</a>> a écrit :</p>
<p>Hello,</p>
<p>Oui c est au niveau de l'envoi des 1000 load_kcoeff dans tous les modes mais cela ne veut pas forcement dire que c est elle.</p>
<p>J'ai fait un test unitaire qui envoie les 1000Tc en standby et cela fonctionne.</p>
<p>Le script du SVS-0022 est plus complexe et je prèfere circonscrire le pb avant de vous inonder de mails.</p>
<p>A+</p>
<p>Véronique</p>
<p>Le 21/12/2022 à 12:52, Alexis Jeandet a écrit :</p>
<p>Hello,</p>
<p>Tu sais sur quelle TC il plante? Est-ce la même à chaque fois?</p>
<p>Alexis.<br />On Wed, 2022-12-21 at 12:46 +0100, Véronique Bouzid wrote:</p>
<p>Hello</p>
<p>Pour info, je viens de planter le soft de vol sur le test de la SVS-<br />0022.</p>
<p>le plantage est reproductible, je l'ai rejoué 2 fois. C</p>
<p>Il faut donc que je trouve le pourquoi. Je renseignerai le REdmine<br />quand j'aurai un peu plus d'infos.</p>
<p>Bon Noel à tous.</p>
<p>Véronique</p>
</blockquote> LFR-FSW - Bug #3948 (Closed): FSW <= 3.3.0.7 : fluctuation de l'amplitude des ASM avec signal sta...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39482022-04-04T08:23:14Zbruno katra
<p>Avec 3.3.0.7 matrices par défaut : on injecte la même fréquence sur B1, B2, B3, E1 et E2 : <br />l'amplitude ASM des termes diagonaux change à chaque ASM, on la voit osciller sur le GSE, voir vidéos et commentaires dans <a class="issue tracker-1 status-2 priority-2 priority-default" title="Bug: Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires. (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3936">#3936</a>.</p> DECOM LFR - Bug #3947 (Closed): Problème de format dans output ASCII des ASM dans DECOM <=0r124https://hephaistos.lpp.polytechnique.fr/redmine/issues/39472022-04-01T14:34:58Zbruno katra
<p>Avec des valeurs très élevées les floats se touchent rendant les valeurs illisibles :</p>
<p>Exemple:</p>
<ol>
<li>SOURCE DATA BEGIN - Offset in the file (byte pos): 20300 #####</li>
<li>PA_LFR_PKT_CNT_ASM: 3 #####</li>
<li>PA_LFR_PKT_NR_ASM: 1 #####</li>
<li>Number of blocks/samples to read : 32</li>
<li>Acquisition Time (first sample): </li>
<li>Sync bit : 0</li>
<li>Raw Integer (unit of 2^-16 seconds) : 46014206509194</li>
<li>Seconds : 702121071.0021057128906250<br /> 84374110208.0000000000176146710528.0000000000 76289605632.0000000000-190448828416.0000000000168695201792.0000000000 38721120.0000000000 -11585246.0000000000 32918624.0000000000 -20688280.0000000000436719157248.0000000000-245066317824.0000000000524383813632.0000000000 70362424.0000000000 -59197352.0000000000 50017824.0000000000 -72955144.0000000000767165726720.0000000000 -110564408.0000000000 -51267808.0000000000 -115667424.0000000000 -19119120.0000000000 19360.7246093750 17947.7539062500</li>
</ol> LFR-FSW - Bug #3941 (Closed): Calcul des BP2 erroné pour F2 [3.3.0.7 avec matrices unitaires]https://hephaistos.lpp.polytechnique.fr/redmine/issues/39412022-03-28T16:40:45Zthomas chust
<p>A F2 le calcul des ASM semble correct sur toute la bande de fréquence ( <a class="issue tracker-1 status-2 priority-2 priority-default" title="Bug: Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires. (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3936">#3936</a> ). Voir par exemple les résultat des CTC-902 ou CTC-912. En utilisant les ASM des ces tests j'ai reconstruit des BP2. Normalement à quelques imprécisions près on devrait retrouver les BP2 calculés à bord. Mais ce n'est pas ce que j'observe: aucune correpondance, tout semble faux. Pour vérifier que je ne me suis pas planté complétement, j'ai refait le même type de calcul/comparaison mais avec le run du 14 mars qui utilise la 3.2.0.24 (F2-64Hz-2Vpp_on_E1E2B1B2B3): là pas de pb je retrouve bien ce qu'il faut.</p>
<p>A suivre ...</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 #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>