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 #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 - Task #3171 (Closed): GCOV pour TEST-TYPEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31712018-10-30T15:41:01ZVeronique bouzid
<p>Peux-tu m extraire la couverture de test en 3.2.0.22.</p>
<p>Les fichiers sont rangés dans data/R3++/3.2.0.22/1.1.91/GCOV/TEST-TYPE</p> LFR-FSW - Task #3166 (Closed): GCOV pour SVS-0003https://hephaistos.lpp.polytechnique.fr/redmine/issues/31662018-10-29T14:58:38ZVeronique bouzid
<p>Le CRC comprend 2 octets, le test ne changé que le dernier octet du CRC.</p>
<p>J ai donc rajouté le test pour le 1er octet du CRC</p>
<p>Les fichiers de tests (2018_10_29-15_50_08*) sont rangés dans /home/validation/data/R3++/3.2.0.22/1.1.91/GCOV/SVS-0003</p> LFR-FSW - Task #3165 (Closed): GCOV pour test SUB-TYPE vs LONGUEURhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31652018-10-29T12:35:24ZVeronique bouzid
<p>Analyse GCOV du test décrit ci-dessous.</p>
<p>Ce test se nomme /opt/VALIDATION_R3plusplus/lfrverif/LFR_SVS/SVS-0003/send_bad_length_vs_subtype.py.<br />Il envoie un TC_LFR_DISABLE_CALIBRATION qui a une longueur de 14 octets au lieu de 12.<br />Cette TC sera refusée lors de la phase d'acceptance suite à la comparaison de longueur attendue pour le sub-type = 63.</p>
<p>En réponse à cette TC, on aura une TM_LFR_TC_EXE_CORRUPTED avec les champs suivants</p>
<p>PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=63, <br />PA_RPW_PKT_LEN_RCV_VALUE=7, PA_RPW_PKT_DATFIELDSIZE_CNT=7, <br />PA_RPW_RCV_CRC=0x8f8c, PA_RPW_COMPUTED_CRC=0x8f8c</p>
<p>Le resultat du test se trouve dans /home/validation/data/R3++/3.2.0.22/1.1.91/GCOV/TEST-NEW.</p> LFR-FSW - Task #3164 (Closed): Gcov pour test SVS-0074https://hephaistos.lpp.polytechnique.fr/redmine/issues/31642018-10-29T11:23:47ZVeronique bouzid
<p>Hello</p>
<p>Peux tu extraire le GCOV pour le test SVS-0074 joué sur 3.2.0.22.</p> LFR-FSW - Task #3149 (Closed): Gcov pour ce test TC-TOO-SHORThttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31492018-10-22T09:47:18ZVeronique bouzid
<p>hello<br />Peux-tu me generer le rapport pour ce test.<br />Le test correspond à l envoi dune TC trop courte (<a class="issue tracker-4 status-5 priority-2 priority-default closed" title="Task: Envoi d une TC dont la taile est inferieure à 16 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3146">#3146</a>)<br />merci.</p> LFR-FSW - Task #1067 (Closed): Preparation Datapack R3++https://hephaistos.lpp.polytechnique.fr/redmine/issues/10672017-04-20T08:30:18ZVeronique bouzid
<p>Voici le bilan des documents à fournir envoyé par William.</p>
<p>Ci-joint le document, j'ai noté dans toutes les colonnes les issues JIRA encore notées "Opened" ou notées "reopened" pour ne pas les oublier.</p>
<p>Il est possible que vous ayez plus de documents à produire que ceux que j'ai noté car je suis reparti de la liste R3 pour faire l'état => e.g. si vous avez créé de nouveaux documents produits, ils ne sont pas dans la liste que j'envoie.<br />De mon côté je suis en train de dépouiller l'analyse Logiscope et j'espère vous faire un retour pour vendredi.</p> LFR-FSW - Support #956 (Closed): Documenter le mecanisme associé à SSS-CP-EQS-526https://hephaistos.lpp.polytechnique.fr/redmine/issues/9562017-03-02T12:30:12ZVeronique bouzid
<p><del>Expliquez comment la moyenne des 16 dernieres valeurs du champ electrique est calculé.</del></p>
<p>Il faudrait détailler dans une prochaine release du RPW-MEB-LFR-SPC-00003-1-12_technical_specifications le mécanisme du filtre IIR (paramètres...)<br />Si possible pour le DP R3++ sinpn pour la release suivante. La SRS fait référence à la tech spec pour l'implémentation du filtre.</p> LFR-FSW - Support #714 (Stalled): Parametrage TCPhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7142016-06-27T14:05:27ZVeronique bouzid
<p>suite au transfert du disque de pc-faust9 dans pc-solar3, la valeur par défaut du champ Server IP dans l onglet TCP server du SpwPlugin0<br />est positionné à une mauvaise valeur, idem dans l onglet connection du LFRControlPlugin0)<br />Il faut donc mettre dans les scripts d'init les 2 lignes suivantes<br />SpwPlugin0.TCPServerSetIP("127.0.0.1")<br />LFRControlPlugin0.SetSpwServerIP(127,0,0,1)<br />indiquant que l'on utilise l'adresse ip du localhost.</p>
<p>Il faut chercher pourquoi Soc veut utiliser l'adresse virtuelle de la machine<br />virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500<br /> inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255<br /> ether 52:54:00:54:9d:28 txqueuelen 1000 (Ethernet)<br /> RX packets 0 bytes 0 (0.0 B)<br /> RX errors 0 dropped 0 overruns 0 frame 0<br /> TX packets 0 bytes 0 (0.0 B)<br /> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0</p> LFR-FSW - Support #596 (Stalled): Mise à jour logiciel LFR-SGSEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5962016-01-27T07:47:27ZVeronique bouzid
<p>Il faudrait mettre à jour le logiciel LFR-SGSE pour visualiser sur l'interface HK les nouveaux champs<br />implémentés.</p> SocExplorer - Bug #498 (New): Timecode + timegen en mode router non fonctionnelshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4982015-09-18T11:35:50ZVeronique bouzid
<p>Timecode:<br />Revoir la fonction SendOneTimecode</p>
<p>Timegen:<br />la procedure manuelle d'utilisation de Timegen fonctionne.<br />Investiger pourquoi en automatique le mode router ne fonctionne pas.</p> SocExplorer - Feature #497 (In Progress): Ajouter une fonction retournant l'etat du cachehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4972015-09-18T11:19:35ZVeronique bouzidLFR-FSW - Support #486 (Feedback): SSS-CP-FS-340 : Design or Testhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4862015-08-18T06:46:10ZVeronique bouzid
<p>Hello,<br />Je m'interroge sur ce requirement<br />SSS-CP-FS-340<br />The RPW Flight Software shall maintain a local time with:<br />− a resolution of at least SY_RPW_TIME_RESOLUTION = 1 ms and a relative accuracy of<br /> SY_RPW_TIME_ACCURACY = 500 μs for the DAS and the three analyzers.<br />− a resolution of at least SY_DPU_DBS_TIME_RESOLUTION = 10 ms and a relative<br /> accuracy of SY_DPU_DBS_TIME_ACCURACY = 1 ms for the DBS.</p>
<p>Il est associé dans la SRS à REQ-LFR-SRS-5300_Ed2.<br />Dans notre fichier SSS-SRS-SVS-compliance_matrix_LFR_V2-1.2.xlsx , il apparait comme un test SVS-0020. Le script associé <br />est time_resolution.py (ce qui ne correspond pas à ce qui est ecrit dans le fichier ). Le nom est internal_time_consistent.py,<br />qui est un script de dépouillement.</p>
<p>Ma question est la suivante, <br />Je ne vois pas comment vérifier ce requirement et pour moi, c'est un test de Design.</p>
<p>J ai assigné ce point à Paul et mis Bruno en observateur ainsi que moi.</p> LFR-FSW - Bug #362 (Closed): CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000 https://hephaistos.lpp.polytechnique.fr/redmine/issues/3622015-03-10T11:44:13ZVeronique bouzid
<p>Le systeme est à l heure (setTime.py),<br />on joue le script /home/validation/SCRIPT/just_normal_mode.py quijoue le Normal Mode durant 2h 1mn</p>
<p>La premiere salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 montre un mauvais champ PA_LFR_ACQUISITION_TIME qui vaut 0x000000000000.</p>
<p>11:42:31.207358, TC_LFR_ENTER_MODE, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000000000<br />11:42:31.239434, TM_LFR_TC_EXE_SUCCESS, TIME=0x1c7f20255cad<br />11:45:19.192084, TM_LFR_SCIENCE_NORMAL_CWF_F3, <strong>PA_LFR_ACQUISITION_TIME=0x000000000000</strong><br />11:45:19.232713, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x0000002a0000<br />11:45:19.264199, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x000000540000<br />11:45:19.278873, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x0000007e0000<br />Le delta entre chaque TM_LFR_SCIENCE_NORMAL_CWF_F3 est bon (2a = 42s).</p>
<p>Par contre la deuxieme salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 est correcte<br />11:48:06.886975, TM_LFR_HK, TIME=0x1c7f21750170, HK_LFR_MODE: NORMAL = 1<br />11:48:07.190201, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f20cd4c2e<br />11:48:07.211115, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f20f74c2e<br />11:48:07.242629, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f21214c2e<br />11:48:07.255938, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f214b4c2e</p>
<p>Les fichiers résultats sont dans /home/validation/data/R2+/JUST-NORMAL</p>
<p>Contexte du test<br />-----------------<br />FSW 2.0.2.2<br />VHDL 1.1.63<br />EM 1<br />SocExplorer 0.4.7 (attention s affiche 0.4.5 dans le fichier Nb.txt)<br />StarDundee spacewire<br />Mini-LFR n°5 en mode TIMEGEN</p>