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 - 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 - Task #3199 (Closed): Analyse couverture de tests 3.2.0.24https://hephaistos.lpp.polytechnique.fr/redmine/issues/31992018-11-13T09:46:29ZVeronique bouzid
<p>Tout se passe sur la machine rangiroa<br />rep = /home/bouzid/LFR/GCOV_3.2.0.24<br />ensuite les répertoires de test /home/bouzid/LFR/GCOV_3.2.0.24/SVS-xxxx.</p>
<p>Les répertoires SVS comprenant plusieurs scripts de test sont traités indépendamment, par exemple <br />SVS-0012 SVS-0012-step2 SVS-0012-burst SVS-0012-normal SVS-0012-sbm1 SVS-0012-sbm2</p>
<p>Les variables d environnement necessaires sont<br />export DROOT=${HOME}/LFR<br />export SGCOV=${DROOT}/LFR_FSW/libgcov/build_gcov_files.py<br />export DBUILD=${DROOT}/build-LFR_FSW-Desktop_Qt_5_11_2_GCC_64bit-Debug/<br />export DTEST=${DROOT}/GCOV_3.2.0.24</p>
<p>Chaque répertoire de test a son analyse gcov unitaire. On se met au debut de l arborescence de test<br />cd ${DTEST}<br />${SGCOV} -r ${DBUILD} -o /home/bouzid/LFR/GCOV_3.2.0.24/SVS-0053/ /home/bouzid/LFR/GCOV_3.2.0.24/SVS-0053/gcov_out_2018-11-13\ 08\:49\:49.309256.txt<br />puis on execute le script /home/bouzid/LFR/lance_rapport SVS-xxxx.</p>
<p>Les fichiers*.html seront crées dans le repertoire de test .</p>
<p>Ensuite pour obtenir l analyse complète, on se met dans le répertoire /home/bouzid/LFR/GCOV_3.2.0.24 et on lance la commande<br />../LFR_FSW/libgcov/gcovr.py -s ../LFR_FSW -o . -g /opt/rtems-4.10/bin/sparc-rtems-gcov .<br />ou bien le script /home/bouzid/LFR/lance_final</p>
<p>Liste des tests joués<br />SVS-0002 à SVS-0014 SVS-0018 à SVS-0022 SVS-0026 à SVS-0034 SVS-0038 SVS-0040 à SVS-0044 SVS-0053 à SVS-0057<br />SVS-0059 SVS-0064 à SVS-0065 SVS-0067 SVS-0069 SVS-0070 SVS-0071 SVS-0073 SVS-0074 SVS-0076 à SVS-0079 SVS-0081 à SVS-0083 SVS-0086 SVS-0089 à SVS-0091 SVS-0095 SVS-0096</p> LFR-FSW - Support #1091 (Feedback): Lost some BP packets in BURST modehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10912017-04-27T09:51:05ZVeronique bouzid
<p>1 test "CAS NOMINAL" <br />on entre en burst mode<br />17:34:51.300563, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />17:34:52.481738, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f503ffff<br />17:34:52.537164, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f504000a</p>
<p>17:34:53.482246, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5050000<br />17:34:53.537797, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f505000a</p>
<p>17:34:54.482316, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5060000<br />17:34:54.537483, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f506000a</p>
<p>17:34:55.481104, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5070000<br />17:34:55.534692, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f507000b</p>
<p>17:34:56.486681, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x44a32a03c608<br />17:34:56.489927, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x44a32a03c608</p>
<p>17:34:56.527804, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />17:34:56.548004, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x44a32a03c612<br />17:34:56.587099, TM_LFR_SCIENCE_BURST_BP2_F1, TIME=0x44a32a03c612<br />17:34:56.587799, TM_LFR_TC_EXE_SUCCESS, TIME=0x44a32a04efa2</p>
<p>17:34:56.920005, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x44a32a050001</p>
<p>Ce cas est nominal. On recoit bien tous les produits BURST meme apres le passage en SBM1.<br />5 BURST_BP1_F0<br />5 BURST_BP1_F1<br />1 BURST_BP2_F0<br />1 BURST_BP2_F1</p>
<p>-Le meme test rejoué " ERREUR" <br />16:27:43.862845, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />16:27:43.871156, TM_LFR_TC_EXE_SUCCESS, TIME=0x318b8203e9a3</p>
<p>16:27:45.049608, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82040001<br />16:27:45.105166, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8204000b</p>
<p>16:27:46.050847, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82050001<br />16:27:46.106364, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8205000b</p>
<p>16:27:47.049695, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82060001<br />16:27:47.104954, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8206000c</p>
<p>16:27:48.049311, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82070001<br />16:27:48.103473, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8207000c</p>
<p>16:27:49.055988, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x3d633003c8cd<br />16:27:49.058668, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x3d633003c8cd</p>
<p>16:27:49.084134, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />16:27:49.094502, TM_LFR_TC_EXE_SUCCESS, TIME=0x3d633004ebbe<br />16:27:49.476704, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x3d6330050000</p>
<p>--> la il nous manque BURST_BP1_F1 et un BURST_BP2_F1 un on a seulement recu<br />5 BURST_BP1_F0<br />4 BURST_BP1_F1<br />1 BURST_BP2_F0</p>
<p>Ma piste s oriente vers le changement de mode qui resette les buffers alors parfois les produits burst sont deja dabns la file d attente pour envoi et parfois<br />non</p>
<p>--> Peux-tu expliquer ?</p>
<p>J ai rencontré plusieurs ce petit dysfonctionnement souvent sur le burst mais egalement sur les NORMAL_BP NORMAL_ASM et sur les BP en SBM2.</p>
<p>Je ne classe pas cette issue en BUG car je pense que c'est le comportement de LFR et qu il faut juste documenter ce point.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> LFR-FSW - Support #1090 (Feedback): Back to time managementhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10902017-04-27T07:43:37ZVeronique bouzid
<p>Premier cas de test<br />- LFR a booté, <br />Le soft remonte bien que le timecode est missing et la derniere erreur tracée est coherente avec cela<br />HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, , HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>- Envoi d'une TC_LFR_UPDATE_TIME avec 300ms apres une timecode invalid ( je mets 5)<br />TC_LFR_UPDATE_TIME, CCSDS_VERSION, CP_RPW_TIME=0x38f223010000</p>
<p>sur la TM_LFR_HK<br />HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>--> Le soft ne remonte aucune erreur et donc la derniere erreur tracée est toujours missing.</p>
<p>--> Peux-tu expliquer CELA</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</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 - Feature #593 (In Progress): adapter tm_lfr_period.py au fonctionnement des modeshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5932016-01-26T08:29:15ZVeronique bouzid
<p>Le normal mode ne s'interrompant plus quand on commute vers sbm1 et sbm2, il faut modifier <br />la fonction tm_lfr_period.py qui testait le timing en fonction du mode actif.</p>
<p>Maintenant la prise en compte des TM_LFR_SCIENCE_NORMAL* doit etre global pour vérifier la continuté des timing.</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 #494 (Feedback): Gestion timecode https://hephaistos.lpp.polytechnique.fr/redmine/issues/4942015-09-11T10:33:03ZVeronique bouzid
<p>J'ai travaillé sur la gestion manuelle de l'envoi de timecode.<br />Pour cela on utilise la fonction SpwPlugin0.StarDundeeSendOneTimecode. Parfois, il faut envoyer 2 timecodes de suite pour que la commande<br />TC_LFR_UPDATE_TIME soit prise en compte, parfois un seul suffit. L'effet de bord est que si les 2 timecodes sont pris en compte, le temps interne de LFR est positionné au temps contenu<br />dans la TC_LFR_UPDATE_TIME + 1s. Donc cela n'etait pas concluant.<br />En effet, la TC_LFR_UPDATE_TIME se traduit par l'ecriture du temps dans le registre COARSE TIME LOAD et l'arrivée du timecode va ecrire ce registre dans le registre COARSE TIME. La reception du 2eme<br />timecode lui, incrementera de 1 ce temps.</p>
<p>--> Conclusion ce n'est pas ce que l'on veut.</p>
<p>En fait je me suis rendue compte que si je resette la carte LFR, je relance le test avec le couple TC_LFR_UPDATE_TIME + 1 timecode = 1, cela<br />fonctionne systématiquement.</p>
<p>Ma conclusion est donc que la remise à zero du timecode géré par le spw n'est effectuée que sur le reset et que meme si je ferme socexplorer<br />je conserve la valeur du dernier timecode que j ai envoyé.</p>
<p>Pour valider cette conclusion, j'ai lu la doc grlib.pdf de Gaisler et j'ai été aidé par Alexis.</p>
<p>J'ai donc écrit un petit script qui lit le registre nommé Time register (0x800000514) dans l'onglet GRSPW et qui contient sur 8 bits <br />- Time control flags (TCTRL) = 2 bits = b7 et b6<br />- Time counter (TIMECNT) = 6 bits = b5 à b0<br />Attention, cela correspond à la valeur du dernier timecode valide et non le nbre de timecode valides. Ce registre n'est accessible qu'en lecture et il est à l'adresse<br />0x800000514</p>
<p>Pour le lire, j ai utilisé la fonction SpwPlugin0.Read <br />et ma théorie s'est vérifiée, quand on sort de socexplorer , il y a conservation de ce registre.</p>
<p>Conclusion, avant d'envoyer un time code,<br />1- il faut lire la valeur contenue dans 0x800000514<br />2- incrementer cette valeur et l envoyer avec SpwPlugin0.StarDundeeSendOneTimecode</p>
<p>Voici donc la séquence à mettre<br />Lecture du timer counter<br />loc_time = SpwPlugin0.Read(0x80000514, 1)<br />timec = loc_time<sup><a href="#fn0">0</a></sup> & 0xff<br />print hex(timec)</p>
<p>timecode=int(timec)+2<br />print timecode<br />SpwPlugin0.StarDundeeSendOneTimecode (timecode)</p>
<p>Remarque<br />--------<br />Comme on ne s interesse pas aux 2 bits de controles, <strong>le masque devrait etre 3f au lieu de ff.</strong><br />En effet les timecodes sont modulo 64.<br />Je l'ai egalement vérifié si j'ecris SpwPlugin0.StarDundeeSendOneTimecode (255) et que je lis le registre, j obtiens en binaire 00111111 soit 3f<br />soit 63.</p>
<p>Autre test, j ai envoyé la sequence suivante<br />py > SpwPlugin0.StarDundeeSendOneTimecode (6)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (254)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (255)</p>
<p>--> le registre ne s'est mis à jour que lors de l'envoi de 255 , car 6 n'etait pas valide, 254 pas valide<br />mais 255 oui car increment de 1/ à la valeur précédente.</p>
<p>Voila ma conclusion. <br />Par contre, on voit bien que 254 a été conservé puisque 255 a été validé, mais je ne sais pas ou ???</p> LFR-FSW - Task #492 (New): Implementation Timing LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4922015-09-10T12:32:30ZVeronique bouzid
<p>Ces informations sont extraites du document RPW-SYS-SSS-00013-LES_Issue3_rev3_Software_System_Specification_bars.pdf</p>
<p>1- Liste des requirements liés au Timing (section Time management 4.1.4)</p>
<p>SSS-CP-FS-340 REQ-LFR-SRS-5300 SVS-0020<br />SSS-CP-FS-350 REQ-LFR-SRS-5217 Design<br />SSS-CP-FS-360 REQ-LFR-SRS-5218 SVS-0011<br />SSS-CP-FS-370 REQ-LFR-SRS-5219 SVS-0012<br />SSS-CP-FS-376 REQ-LFR-SRS-5237 noté Design mais on a un test<br />SSS-CP-FS-380 REQ-LFR-SRS-5220 SVS-0013<br />SSS-CP-FS-390 REQ-LFR-SRS-5301 Design<br />SSS-CP-FS-400 REQ-LFR-SRS-5221 Design<br />SSS-CP-FS-405 REQ-LFR-SRS-5238 SVS-0014<br />SSS-CP-FS-410 REQ-LFR-SRS-5222 SVS-0076</p>
<p>Résumé de ma compréhension du timing LFR</p>
<p>le développement du software est axé principalement sur le fonctionnement nominal :<br />- toutes les secondes, LFR recoit du DAS le couple suivant<br /> - une commande TC_LFR_UPDATE_TIME ( CTR Time Update command ou bien CTR SpaceWire command packet)<br /> - 300ms aprés un timecode valide (SpaceWire time code)</p> LFR-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 - Feature #481 (Closed): Cohérence/Intégrité sur TC_LFR_LOAD_NORMAL_PARhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4812015-08-10T11:27:10ZVeronique bouzid
<p>Voici les régles appliquées pour valider las paramètres utilisés dans TC_LFR_LOAD_NORMAL_PAR:<br />6 parametres sont disponibles pour configurer le NORMAL MODE</p>
<p>SY_LFR_N_SWF_L <br />SY_LFR_N_SWP_P<br />SY_LFR_N_ASM_P<br />SY_LFR_N_BP_P0<br />SY_LFR_N_BP_P1 <br />SY_LFR_N_CWF_LONG_F3</p>
<p>Le parametre SY_LFR_N_CWF_LONG_F3 étant codé sur 1 bit,aucun test n'est effectué.</p>
<p>2 types de vérification sont effectués<br />- le parametre doit appartenir à son domaine de définition (cf ICD)<br />- le parametre doit etre coherent avec les objectifs scientifiques</p>
<p>Voici l'ordre dans lequel les parametres sont évalués</p>
<p>La référence est ICD 3.9</p>
<p><strong>SY_LFR_N_SWF_L</strong><br />--> ICD indique [16,2048] par défaut 2048<br />SY_LFR_N_SWF_L = 2048 --> VALEUR FIXEE, on ne peut pas la modifiée<br /> --> INCONSISTENT si cette valeur n'est pas 2048<br /> <strong>Voir s'il faut mettre à jour l'ICD</strong></p>
<p><strong>SY_LFR_N_SWP_P</strong> <br />--> ICD indique [16,65528] par défaut 300<br />SY_LFR_N_SWP_P < 16<br /> --> INCONSISTENT <br /><strong>Par contre 65528 n'est plus correcte (plus besoin de multiple de 8), on peut accepter 65535.<br /> --> Mettre à jour l'ICD</strong></p>
<p><strong>Attention, je me suis rendue compte que Le parametre SY_LFR_N_BP_P0 etait testé avant SY_LFR_N_ASM_P (cf Bug xxx)</strong></p>
<p><strong>SY_LFR_N_BP_P0</strong><br />Aucun domaine de définition valeur par défaut = 4<br />SY_LFR_N_BP_P0 < 4<br /> --> INCONSISTENT <br /> <strong>Voir s'il faut mettre à jour l'ICD</strong></p>
<p><strong>SY_LFR_N_ASM_P</strong><br />Aucun domaine de définition valeur par défaut = 3600s<br />SY_LFR_N_ASM_P = 0<br /> --> INCONSISTENT <br /> <strong>Voir s'il faut mettre à jour l'ICD</strong></p>
<p><strong>SY_LFR_N_BP_P1</strong> <br />Aucun domaine de définition valeur par défaut = 20s<br />SY_LFR_N_BP_P1 < 20<br /> --> INCONSISTENT <br /> <strong>Voir s'il faut mettre à jour l'ICD</strong></p>
<p><ins>Cohérence entre parametres</ins><br />Ces vérifications ne sont effectuées que si les paramètres respectent leur domaine de définition.</p>
<p>1- on accepte que SY_LFR_N_ASM_P = 4s si SY_LFR_N_BP_P0 = 4s par exemple, cela un sens scientifiquement<br />donc<br />si SY_LFR_N_ASM_P est un multiple de SY_LFR_N_BP_P0 --> OK</p>
<p>2- on accepte que SY_LFR_N_BP_P1 = 24 et SY_LFR_N_BP_P0 = 4s<br />donc<br />si SY_LFR_N_BP_P1 est un multiple de SY_LFR_N_BP_P0 --> OK</p>
<p>De meme SY_LFR_N_BP_P0 = SY_LFR_N_BP_P1 = 255 sera accepté</p> LFR-FSW - Task #398 (New): Utilisez le script periodicity.py sur les tests de Geraldhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3982015-04-27T13:32:54ZVeronique bouzid
<p>Il serait bien d'utiliser le script periodicity.py que Bruno a développé<br />pour dépouiller les tests de charge (analyse des fichiers de type *_packet_log.data, format ecrit par Paul).</p>
<p>Le script de Gerald verif_fields.py gere un fichier tm_time.txt dont le format<br />n'est pas trop éloigné de celui de Paul.</p>
<p>Il faudrait transformer le format<br />07:57:08.364223, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x0000001133f7</p>
<p>en<br />2015 3 25 16:22:00:360 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 80000020 5bd2</p>
<p>J ai donc commencé par <br />1- Recuperer la date du fichier à traiter pour l'ecrire dans le fichier (verif_fields.py) + passage de l argument<br />2- reformatter les infos comme il faut (supprimer les micros secondes, parser le temps...)<br />3- creer un fichier resultat avec la nomemclature <strong><em>packet_log.data et qui ne contient que les TM</em></strong></p>