Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-02-13T10:10:15ZRedmine
Redmine LFR-FSW - Task #4026 (Closed): Analyse GCOVhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40262023-02-13T10:10:15ZVeronique bouzid
<p><strong>Début de la couverture de Test en 3.3.0.16</strong></p>
<p>Une quinzaine de tests ont été joués. Avant de pousser plus loin, il faudrait traiter ses tests et évaluer la couverture atteinte.</p>
<p>Sur pc-solar3, dans le répertoire /opt/VALIDATION_R3.3/GCOV/3.3.0.16, voici les fichiers à traiter:</p>
<p>gcov_out_2023-02-13 09:10:52.635355.txt<br />gcov_out_2023-02-13 09:12:32.358845.txt<br />gcov_out_2023-02-13 09:15:53.533775.txt<br />gcov_out_2023-02-13 09:17:58.219268.txt<br />gcov_out_2023-02-13 09:23:23.893858.txt<br />gcov_out_2023-02-13 09:33:27.972367.txt<br />gcov_out_2023-02-13 09:37:47.458757.txt<br />gcov_out_2023-02-13 09:39:33.827127.txt<br />gcov_out_2023-02-13 09:41:52.977440.txt<br />gcov_out_2023-02-13 10:23:51.069120.txt (SVS-0002 à SVS-0010 + SVS-0059)</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 #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 #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 - Task #3918 (Closed): Mise à jour des 2 DEFINE PA_LFR_KCOEFF_BLK_NR pour le KCOEFF_DUMP https://hephaistos.lpp.polytechnique.fr/redmine/issues/39182022-01-11T13:35:26Zbruno katra
<p>En référence à <a class="issue tracker-2 status-5 priority-3 priority-high3 closed" title="Feature: La TM_KCOEFF_DUMP n'a plus la structure dédcrite dans l'ICD (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3905">#3905</a> : il faudrait mettre à jour le FSW avec les valeurs de DEFINE suivantes :<br />#define KCOEFF_BLK_NR_PKT1 26<br />#define KCOEFF_BLK_NR_PKT2 13</p> Helioswarm-SCM - Task #3845 (Closed): Order missing parts for BBMhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/38452021-05-14T09:54:01ZAlexis Jeandet
<p>We have to check which parts are missing for the BBM PCB and order them ASAP.</p> LFR-FSW - Task #3167 (Closed): Livraison de 3.2.0.23 avec gcovhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31672018-10-30T08:58:27ZAlexis Jeandet
<p>Nouvelle version avec le code mort désactivé (#ifdef ENABLE_DEAD_CODE) et le version min de CMake est baissée à 3.5.</p> LFR-FSW - Task #3134 (Closed): Livraison de 3.2.0.22 avec gcovhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31342018-10-10T18:17:51ZAlexis Jeandet
<p>Nouvelle version intégrant les modifs logiscope, compilée en -O2 et avec une modif expérimentale de gcov.</p> LFR-FSW - Bug #1080 (Closed): Problème amplitude des waveforms sur l'EQMhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10802017-04-25T09:04:04Zbruno katra
<p>Depuis hier, remontage de la discospace sur l'EQM pour faire des tests sur la NC287 du CNES (pb de saut de syncro dans certains SWF).</p>
<p>On injecte 2Vpp sans offset : les SWF montrent une sinusoide entre -9000 et 0 counts.<br />Autres tests : injection de 6Vpp avec 0.1Hz et 0.2Hz => la dynamique reste entre -7000 et 0 counts dans le moyennage HK@F3 (voir image en PJ)</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2293/2017-04-25-10-49-29.png" alt="" /></p>
<p>+ le même test au niveau SWF montre une saturation à 0 et -9000 (voir image en PJ) :<br /><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2292/2017-04-25-10-49-58.png" alt="" /></p>
<p>Les mêmes tests avant ne montraient pas ce comportement.</p> LFR-FSW - Bug #1033 (Closed): Moyennage à 16Hz dans les HK : nouveau filtre IIR implémenté donne ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10332017-03-28T09:26:48Zbruno katra
<p>Tests joués en 3.2.0.10 avec Mini-LFR et EM avec un signal à 5Hz +/-3V sur V et un signal à 0.1Hz +/-3V sur E1 :<br />Mode Normal pendant environ 8 minutes.<br />Les CWF@F3 sont nominaux</p>
<p><strong>Résultats avec Mini-LFR :</strong></p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2198/3.2.0.10-hk-mini.png" alt="" /></p>
<p><strong>Résultats avec EM :</strong></p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2197/3.2.0.10-hk-EM.png" alt="" /></p>
<p>Bien que l'on voit une oscillation régulière qui ressemble à du 0.1Hz, on ne retrouve pas de courbes propre à 0.1Hz sur E1 : les amplitudes sont très faibles de plus.</p> LFR-FSW - Task #1031 (Closed): 3.2.0.10https://hephaistos.lpp.polytechnique.fr/redmine/issues/10312017-03-28T06:13:23Zpaul leroy
<pre>
****************************
*** 3.2.0.10 *** 28 MAR 2017
____________________________________
__fsw__Changeset: 360 (cae68a260aa2)
AJE filter implemented in AVGV
</pre> LFR-FSW - Bug #863 (Closed): Produits SCIENCE : périodes des ACQUISITION_TIME et TIME non nominau...https://hephaistos.lpp.polytechnique.fr/redmine/issues/8632016-12-28T12:23:00Zbruno katra
<p>Les produits BP arrivent à la cadence attendue mais avec des champs ACQUISITION_TIME qui n'ont pas la bonne période seulement lorsqu'on utilise TIMEGEN.<br />Exemple:<br />2016 12 28 <strong>12:33:59:717</strong> TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x <strong>1ff66d6c</strong> ffeb<br />2016 12 28 <strong>12:34:19:797</strong> TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x <strong>1ff66d7a</strong> ffcf<br />2016 12 28 12:34:39:771 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d88 ffb4<br />2016 12 28 12:34:59:771 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66d96 ff9a<br />2016 12 28 12:35:19:782 TM_LFR_SCIENCE_NORMAL_BP2_F0 time = 0x 1ff66da4 ff81</p>
<p>Les BP2 sont bien arrivés toutes les 20s mais leur ACQUISITION_TIME est espacé de 14s</p>
<p>Idem BP1:<br />2016 12 28 <strong>12:33:43:773</strong> TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x <strong>1ff66d60</strong> ffff<br />2016 12 28 <strong>12:33:47:711</strong> TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x <strong>1ff66d63</strong> fffb<br />2016 12 28 12:33:51:711 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d66 fff5<br />2016 12 28 12:33:55:774 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1ff66d69 fff0</p>
<p>Les BP1 ont bien arrivés toutes les 4s mais leur ACQUISITION_TIME est espacé de 3s</p>
<p>Idem pour les ASM : 3s au lieu de 4s<br />Idem pour les SWF : 15s au lieu de 22s</p>
<p>NB : les mêmes tests SANS TIMEGEN ne montrent pas le problème.<br />NB2 : Le bug n'était pas présent en R3 + ancien VHDL (nous avons revérifié les résultats des tests de charge effectués en oct 2015)<br /><del>NB2 : il est probable que TOUS les produits soient impactés.</del></p>
<p>Contexte du test<br />---------------------<br />FSW 3.1.0.4<br />VHDL 1.1.91<br />EM1 <strong>avec</strong> TIMEGEN</p> LFR-FSW - Bug #421 (Closed): La carte mini-lfr en TIMEGEN ne fonctionne plus.https://hephaistos.lpp.polytechnique.fr/redmine/issues/4212015-05-27T15:55:17Zbruno katra