Redmine: Issues
https://hephaistos.lpp.polytechnique.fr/redmine/
https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?1508097601
2023-02-13T10:10:15Z
Redmine
Redmine
LFR-FSW - Task #4026 (Closed): Analyse GCOV
https://hephaistos.lpp.polytechnique.fr/redmine/issues/4026
2023-02-13T10:10:15Z
Veronique 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 #4012 (Closed): TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/4012
2023-01-19T10:26:55Z
Veronique 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 #1059 (Closed): Livraison SDD
https://hephaistos.lpp.polytechnique.fr/redmine/issues/1059
2017-04-12T10:11:04Z
Veronique bouzid
<p>Pour le datapack, il faut fournir le SDD.<br />Il nous faudrait le document pour le 30 avril 2017 au plus tard.</p>
LFR-FSW - Bug #981 (Closed): TC_LFR_LOAD_FILTER_PAR not acknowledged
https://hephaistos.lpp.polytechnique.fr/redmine/issues/981
2017-03-16T09:19:03Z
Veronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3++/set_load_filter_par.py.<br />L'envoi d une TC_LFR_LOAD_FILTER_PAR n est pas acquittée</p>
<p>09:56:29.206898,/home/validation/SCRIPT/R3++/set_load_filter_par.py<br />09:56:31.208759,PROXY LOAD is True<br />09:56:45.225339, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:56:50.226504, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:02.227914, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:07.228961, /!\No TM_LFR_TC_EXE_* after time-out (4s).<br />09:57:12.229741,End(/home/validation/SCRIPT/R3++/set_load_filter_par.py)</p>
<p>Les fichiers de données (2017_03_16-09_57_12*) sont rangés dans /home/validation/data/R3++/3.2.0.3/1.1.91/TEST-UNITAIRES/set_load_filter_par.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.3<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p>
LFR-FSW - Bug #976 (Closed): HK_LFR_SC_V_F3 is erroneous
https://hephaistos.lpp.polytechnique.fr/redmine/issues/976
2017-03-13T14:04:08Z
Veronique bouzid
<p>Envoi de N rampes durant 2 mn avec balayage complet de la dynamique (-3.3V à 3.3V).</p>
<p>Nous avons verifié que la decomm fonctionnée donc le probleme doit venir du software de LFR.</p>
<p>Je joins le fichier qui plotte le champ HK_LFR_SC_V_F3 (RampUp_2mn_on_V.png)</p>
<p>le fichier utilisé par les plots est également fourni.</p>
LFR-FSW - Bug #867 (Closed): Fonction setFBinMask: Calcul masque erroné
https://hephaistos.lpp.polytechnique.fr/redmine/issues/867
2016-12-29T11:44:23Z
Veronique bouzid
<p>J ai testé la fonction serFBinMask avec les parametres décrits ci-dessous<br />setFBinMask( fbins_mask, rw_f, deltaFreq, flag );</p>
<p>rw_f = 96.0<br />deltaFreq= 96.0</p>
<p>flag=1</p>
<p>Voila la trace du calcul</p>
<p>--> on trouve 3 bins à masquer 0,1,2<br /><strong>Channel = 0 and Freq = 96.000000</strong><br />binBelow = 1 and binAbove = 1<br />closestBin = 1<br /><strong>bin0 = 0 and bin1= 1 and bin2= 2</strong></p>
<p><ins>le premier masque calculé pour le bin 0</ins><br /> Byte Range is 15 and previous mask is 0xff (condition initiale)<br /> Byte Range is 15 and mask is 0xfe le maque calculé<br />au final<br /> <strong>Byte Range is 15 and current mask is 0xfe</strong></p>
<p><ins>le masque calculé pour le bin 1</ins><br /> Byte Range is 15 and previous mask is 0xfe<br /> Byte Range is 15 and mask is 0xfc le masque calculé<br /> <strong>Byte Range is 15 and current mask is 0xfc</strong></p>
<p>l+e masque calculé pour le bin 2+<br /> Byte Range is 15 and previous mask is 0xfc<br /> Byte Range is 15 and mask is 0xf8 le masque calculé<br /> Byte Range is 15 and current mask is 0xf8</p>
<p>et ensuite le tour en plus lié au k=3<br /> Byte Range is 15 and previous mask is 0xf8<br /> Byte Range is 15 and mask is 0xf8<br /> Byte Range is 15 and current mask is 0xf8</p>
<p>On obtient donc pour rw_f=96 hz et le channel 0, le masque suivant<br />Byte Range is 15 and current mask is 0xf8 ce qui signifie que les 3</p>
<p>Hors le tableau des frequences à F0 est le suivant <br />F0 <br />[ <strong>96 192</strong> 288 384 480 576 672 768<br /> 864 960 1056 1152 1248 1344 1440 1536<br /> 1632 1728 1824 1920 2016 2112 2208 2304<br /> 2400 2496 2592 2688 2784 2880 2976 3072<br /> 3168 3264 3360 3456 3552 3648 3744 3840<br /> 3936 4032 4128 4224 4320 4416 4512 4608<br /> 4704 4800 4896 4992 5088 5184 5280 5376<br /> 5472 5568 5664 5760 5856 5952 6048 6144<br /> 6240 6336 6432 6528 6624 6720 6816 6912<br /> 7008 7104 7200 7296 7392 7488 7584 7680<br /> 7776 7872 7968 8064 8160 8256 8352 8448<br /> 8544 8640 8736 8832 8928 9024 9120 9216<br /> 9312 9408 9504 9600 9696 9792 9888 9984<br /> 10080 10176 10272 10368 10464 10560 10656 10752<br /> 10848 10944 11040 11136 11232 11328 11424 11520<br /> 11616 11712 11808 11904 12000 12096 12192 12288]</p>
<p>et donc on devrait obtenir comme <strong>masque 0xfc</strong> puisque que 96 et 192 doivent etre masquées.</p>
<p>Je rappelle que la fréquence 0 n est pas à considérer comme indiqué dans le REQ-RPW-LFR-2407 du document RPW-MEB-LFR-00003 (Technical specifications)</p>
LFR-FSW - Bug #865 (Closed): Fonction setFBinMask erronée
https://hephaistos.lpp.polytechnique.fr/redmine/issues/865
2016-12-29T10:56:07Z
Veronique bouzid
<p>Pour avancer sur l'analyse du bug <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: Mauvais BIN filtrée suite à reception d'un UPDATE_INFO avec les fréquences RW : décalage de 1 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/864">#864</a> , je me suis permise de récuperer ta fonction setFBinMask et de la tester unitairement.</p>
<p>1- Cette boucle est erronée , la derniere valeur de k doit etre 2 et non 3<br /> for (k = 0; k <= 3; k++)
{<br /> bin = binToRemove[k];</p>
<p>--> la declaration du tableau est int binToRemove[ 3 ];<br />Si on a 3 bins à enlever tu vas superposer 4 masques.</p>
LFR-FSW - Bug #657 (Closed): HK_LFR_xE_CNT doesn't manage the wrap of 8bits counter error
https://hephaistos.lpp.polytechnique.fr/redmine/issues/657
2016-03-09T14:28:44Z
Veronique bouzid
<p>En Analysant le passage à zero des compteurs d'erreurs suivants (HK_LFR_TIMECODE_MISSING et HK_LFR_TIME_NOT_SYNCHRO, j observe bien le passage de 255 vers 0<br />pour les compteurs d'erreur codés sur 8 bits mais l'effet non attendu est que les compteurs HK_LFR_xE_CNT qui eux sont codés sur 16 bits ne sont plus bons car<br />ils representent la somme des erreurs liées à une criticité et donc le fait qu'un compteur passe à 0 diminue la valeur du ce compteur HK_LFR_xE_CNT<br />Voici un extrait du fichier Detail.txt</p>
<p>15:54:46.122923, TM_LFR_HK, TIME=0x000000ff81da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=509,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: NOT_SYNCHRO = 25, HK_LFR_LAST_ER_TIME=0x8000013bd189, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=255</strong>, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254,</strong> HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>15:54:47.122944, TM_LFR_HK, TIME=0x0000010081da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=254,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x000001003270, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=0,</strong> HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254</strong>, HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>Ceci est donc valable pour n'importe quel compteur codé sur 8 bits et utilisé dans une somme.</p>
<p>Les fichiers (2016_02_25-16_00_04-) sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0078/not_synchro.<br />Probleme remonté en lancant verif_fields sur le fichier Detail.txt.<br />Le fichier sss_cp_eqs_050.txt met en evidence les observations et permet de valider les passages à zero des compteurs :</p>
<p>15:54:47.122944, TM_LFR_HK<br />HK_LFR_LE_CNT: res=254; exp>=509 HK_LFR_TIMECODE_MISSING: res=0; exp>=255</p>
<p>15:55:49.123074, TM_LFR_HK<br />HK_LFR_DPU_SPW_TICK_OUT_CNT: res=0; exp>=255 HK_LFR_DPU_SPW_LAST_TIMC: res=0; exp>=63</p>
<p>15:56:50.123381, TM_LFR_HK<br />HK_LFR_LE_CNT: res=1; exp>=256 HK_LFR_TIME_NOT_SYNCHRO: res=0; exp>=255</p>
<p>Le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0078/update_time_not synchro_cnt_wrap.py.</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p>
LFR-FSW - Support #627 (Closed): Commutation immediate
https://hephaistos.lpp.polytechnique.fr/redmine/issues/627
2016-02-14T09:10:52Z
Veronique bouzid
<p>_<br />Sur le test joué en 3.0.0.22, je regarde la commutation<br />NORMAL vers SBM1 car plus facile à valider vu que les produits CWF_F1 sont tout de suite disponibles.</p>
<p>La commutation demandée est immediate, ce qui signifie qu'elle sera effective sur le tick-out d'apres = la seconde suivante.<br />2016 2 13 11:58:53:343 TM_LFR_HK time = 0x 1e51d6fc 6174<br />2016 2 13 11:58:53:512 TM_LFR_TC_EXE_SUCCESS time =* 0x 1e51d6fc 8cf1*<br />2016 2 13 11:58:53:770 TM_LFR_SCIENCE_SBM1_CWF_F1 time =* 0x 1e51d6fc 259d*</p>
<p>Je m'attends donc à voir arriver un produit CWF_F1 proche de 0x 1e51d6fd voire meme au mieux 1e51d6fc eaff (ffff-1500) mais comme on doit avoir 8 buffers, le calcul<br />doit etre FFFF-A800=557F.<br />Ce n'est pas le cas, on a l'impression même que la commutation a été immédiate.</p>
<p>1er groupe<br />2016 2 13 11:58:53:770 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 259d<br />2016 2 13 11:58:53:782 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 3a9d<br />2016 2 13 11:58:53:782 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 4f9d<br />2016 2 13 11:58:53:794 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 649d<br />2016 2 13 11:58:53:794 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 799d<br />2016 2 13 11:58:53:804 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc 8e9d<br />2016 2 13 11:58:53:808 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc a39d<br />2016 2 13 11:58:53:808 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc b89d</p>
<p>2eme groupe (A800 fine-time plus loin)<br />2016 2 13 11:58:54:426 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc cd9d /A800) soit 43008 fine-time<br />2016 2 13 11:58:54:438 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc e29d<br />2016 2 13 11:58:54:438 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fc f79d<br />2016 2 13 11:58:54:450 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd c9d -> la on a franchi la seconde / commutation demandée<br />2016 2 13 11:58:54:450 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 219d<br />2016 2 13 11:58:54:454 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 369d<br />2016 2 13 11:58:54:467 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 4b9d<br />2016 2 13 11:58:54:467 TM_LFR_SCIENCE_SBM1_CWF_F1 time = 0x 1e51d6fd 609d<br />2016 2 13 11:58:54:503 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 1e51d6fd 3da1<br />2016 2 13 11:58:54:735 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 1e51d6fd 7da1</p>
<p>donc on aurait du commencer à voir seulement les produits du 2eme groupe</p>
<p>--> EST CE QUE MON ANALYSE EST CORRECTE?</p>
<p>Autre explication:<br />Tu prends le premier groupe car tu as deja le buffer qui est disponible et tu estimes compatible avec le temps de commutation.</p>
<p>Le second buffer arrive trop loin de la seconde soit 0x 1e51d6fc cd9d + A800 = 0x 1e51d6fd bda1.</p>
<p>QUELLE EST LA BONNE ANALYSE?</p>
<p>Il faut vraiment documenter cette partie pour renseigner la SRS et eventuellement le SUM._</p>
LFR-FSW - Bug #535 (Closed): Field HK_LFR_LAST_EXE_TC_SUBTYPE incorrect if aTC_LFR_LOAD_FBINS_MAS...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/535
2015-10-05T10:23:29Z
Veronique bouzid
<p>La commande TC_LFR_LOAD_FBINS_MASK n'est pas bien décrite dans le packet TM_LFR_HK.</p>
<p>En effet, le champ SERVICE_SUBTYPE: LOAD_FBINS_MASK = 93 devient dans la TM_LFR_HK, HK_LFR_LAST_EXE_TC_SUBTYPE=91.. Par contre les autres champs<br />- HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_TIME=0x8000008f2ebb sont corrects</p>
<p>12:00:09.661454, <strong>TC_LFR_LOAD_FBINS_MASK</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=10208, (PACKET_SEQUENCE_CONTROL=0xe7e0), PACKET_LENGTH=53, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, <strong>SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_FBINS_MASK = 93</strong>, SOURCE_ID: RECOVERY_ACTION_CMD = 112, FBINS_F0_WORD1 = 0xffffffff,FBINS_F0_WORD2 = 0xffffffff,FBINS_F0_WORD3 = 0xffffffff,FBINS_F0_WORD4 = 0xffffffff,FBINS_F1_WORD1 = 0xffffffff,FBINS_F1_WORD2 = 0xffffffff,FBINS_F1_WORD3 = 0xffffffff,FBINS_F1_WORD4 = 0xffffffff,FBINS_F2_WORD1 = 0xffffffff,FBINS_F2_WORD2 = 0xffffffff,FBINS_F2_WORD3 = 0xffffffff,FBINS_F2_WORD4 = 0xffffffff,CRC = 0x1147</p>
<p>12:00:09.670408, <strong>TM_LFR_TC_EXE_SUCCESS</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: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=690, (PACKET_SEQUENCE_CONTROL=0xc2b2), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, <strong>TIME=0x8000008f2ebb</strong>, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe7e0</p>
<p>12:00:09.680432, <strong>TM_LFR_HK</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: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=141, (PACKET_SEQUENCE_CONTROL=0xc08d), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000008f31b4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: NORMAL = 1, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: POWER_ON = 1, SY_LFR_SW_VERSION_N1=3, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=9, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=89, HK_LFR_CPU_LOAD=11.7647058824, HK_LFR_CPU_LOAD_MAX=16.862745098, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_Q_SD_FIFO_SIZE_MAX=4, HK_LFR_Q_SD_FIFO_SIZE=50, HK_LFR_Q_RV_FIFO_SIZE_MAX=1, HK_LFR_Q_RV_FIFO_SIZE=10, HK_LFR_Q_P0_FIFO_SIZE_MAX=1, HK_LFR_Q_P0_FIFO_SIZE=10, HK_LFR_Q_P1_FIFO_SIZE_MAX=1, HK_LFR_Q_P1_FIFO_SIZE=10, HK_LFR_Q_P2_FIFO_SIZE_MAX=1, HK_LFR_Q_P2_FIFO_SIZE=5, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=609, HK_LFR_REJ_TC_CNT=55, HK_LFR_LAST_EXE_TC_ID=0x1ccc, <strong>HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=91,</strong> <strong>HK_LFR_LAST_EXE_TC_TIME=0x8000008f2ebb</strong>, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=41, HK_LFR_LAST_REJ_TC_TIME=0x800000598e1b</p>
<p>Cette fois j'ai bien verifié le fichier tm.csv et les valeurs sont identiques à celles communiquées ci-dessous. Donc pas de probleme de traduction.</p>
<p>le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0019/tm_sequence_counter_loop.py et les fichiers de test <br />sont rangés dans /home/validation/data/R3/3.0.0.9/1.1.89/SVS-0019.</p>
<p><strong>--> Vérifiez le comportement en cas d'erreur en attendant à chaque fois la HK pour vérifier les champs.</strong></p>
<p>J'ai retrouvé un jeu de test datant du 13/05/2015 (/home/validation/data/R3/JUST-STBY-FBINS) , le bug etait déja présent et la version du soft 3.0.0.0.<br />Donc l'erreur ne vient pas des modifications récentes.</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.9<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p>
LFR-FSW - Bug #477 (Closed): R3 *** fields HK_LFR_LAST_REJ_TC_ID and HK_LFR_LAST_REJ_TC_TYPE erro...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/477
2015-07-27T11:50:25Z
Veronique bouzid
<p>Depuis la version 3.0.0.x, il semble que la gestion des commandes rejetées soient devenues erronées.<br />Les informations inscrites dans les TM_LFR_HK concernant ce rejet sont<br />HK_LFR_REJ_TC_CNT<br />HK_LFR_LAST_REJ_TC_ID<br />HK_LFR_LAST_REJ_TC_TYPE<br />HK_LFR_LAST_REJ_TC_SUBTYPE<br />HK_LFR_LAST_REJ_TC_TIME</p>
<p>les champs erronés sont<br />HK_LFR_LAST_REJ_TC_ID<br />HK_LFR_LAST_REJ_TC_TYPE</p>
<p>C'est observé sur <br />TM_LFR_TC_EXE_NOT_EXECUTABLE<br />TM_LFR_TC_EXE_CORRUPTED</p>
<p>Le test utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0003/loop_tm_lfr_tc_exe.py mais n'importe quel test rejetant une TC met en évidence le bug.</p>
<p>le fichier de log est /home/validation/data/R3/3.0.0.3/SVS-0003/2015_06_04-15_48_35-Detail.txt</p>
<p>15:46:37.265176, <strong>TC_LFR_ENTER_MODE</strong> (CP_LFR_MODE=0), CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (<strong>PACKET_ID=0x1ccc</strong>), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6565, (PACKET_SEQUENCE_CONTROL=0xd9a5), PACKET_LENGTH=13, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, <strong>SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: ENTER_MODE = 41</strong>, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0, CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000000000, CRC = 0x1419</p>
<p>15:46:37.284992, <strong>TM_LFR_TC_EXE_NOT_EXECUTABLE</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: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=19, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001d2365, PA_RPW_TC_FAILURE_CODE: TC_NOT_EXE = 42000, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd9a5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=41, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0</p>
<p>15:46:37.342316, <strong>TM_LFR_HK, CCSDS_VERSION_NUMBER</strong> = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=27, (PACKET_SEQUENCE_CONTROL=0xc01b), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000001d31f3, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: OFF = 0, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0, SY_LFR_SW_VERSION_N1=3, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=3, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=68, HK_LFR_CPU_LOAD=0.392156862745, HK_LFR_CPU_LOAD_MAX=1.96078431373, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_Q_SD_FIFO_SIZE_MAX=1, HK_LFR_Q_SD_FIFO_SIZE=50, HK_LFR_Q_RV_FIFO_SIZE_MAX=1, HK_LFR_Q_RV_FIFO_SIZE=10, HK_LFR_Q_P0_FIFO_SIZE_MAX=0, HK_LFR_Q_P0_FIFO_SIZE=10, HK_LFR_Q_P1_FIFO_SIZE_MAX=0, HK_LFR_Q_P1_FIFO_SIZE=10, HK_LFR_Q_P2_FIFO_SIZE_MAX=0, HK_LFR_Q_P2_FIFO_SIZE=5, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=0, HK_LFR_REJ_TC_CNT=1, HK_LFR_LAST_EXE_TC_ID=0x0, HK_LFR_LAST_EXE_TC_TYPE=0, HK_LFR_LAST_EXE_TC_SUBTYPE=0, HK_LFR_LAST_EXE_TC_TIME=0x000000000000, <strong>HK_LFR_LAST_REJ_TC_ID=0x1c00</strong>, <strong>HK_LFR_LAST_REJ_TC_TYPE=0</strong>, HK_LFR_LAST_REJ_TC_SUBTYPE=41, HK_LFR_LAST_REJ_TC_TIME=0x8000001d2365,</p>
<p>ici pour TM_LFR_TC_EXE_CORRUPTED<br />15:46:39.285341, TC_LFR_RESET, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=153, (PACKET_SEQUENCE_CONTROL=0xc099), PACKET_LENGTH=5, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: RESET = 1, SOURCE_ID: MISSION_TIMELINE = 110, /!\CRC = 0x1b65(exp=0x1b64)</p>
<p>15:46:39.30235, TM_LFR_TC_EXE_CORRUPTED, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=25, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001f27a5, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc099, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=1, PA_RPW_PKT_LEN_RCV_VALUE=5, PA_RPW_PKT_DATFIELDSIZE_CNT=5, PA_RPW_RCV_CRC=0x1b65, PA_RPW_COMPUTED_CRC=0x1b64</p>
<p>15:46:39.342327, <strong>TM_LFR_HK</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: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=29, (PACKET_SEQUENCE_CONTROL=0xc01d), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000001f31f4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: OFF = 0, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0, SY_LFR_SW_VERSION_N1=3, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=3, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=68, HK_LFR_CPU_LOAD=0.392156862745, HK_LFR_CPU_LOAD_MAX=1.96078431373, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_Q_SD_FIFO_SIZE_MAX=1, HK_LFR_Q_SD_FIFO_SIZE=50, HK_LFR_Q_RV_FIFO_SIZE_MAX=1, HK_LFR_Q_RV_FIFO_SIZE=10, HK_LFR_Q_P0_FIFO_SIZE_MAX=0, HK_LFR_Q_P0_FIFO_SIZE=10, HK_LFR_Q_P1_FIFO_SIZE_MAX=0, HK_LFR_Q_P1_FIFO_SIZE=10, HK_LFR_Q_P2_FIFO_SIZE_MAX=0, HK_LFR_Q_P2_FIFO_SIZE=5, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=0, HK_LFR_REJ_TC_CNT=2, HK_LFR_LAST_EXE_TC_ID=0x0, HK_LFR_LAST_EXE_TC_TYPE=0, HK_LFR_LAST_EXE_TC_SUBTYPE=0, HK_LFR_LAST_EXE_TC_TIME=0x000000000000, <strong>HK_LFR_LAST_REJ_TC_ID=0x1c00, HK_LFR_LAST_REJ_TC_TYPE=0,</strong> HK_LFR_LAST_REJ_TC_SUBTYPE=1, HK_LFR_LAST_REJ_TC_TIME=0x8000001f27a5</p>
<p>Parfois les 2 champs sont renseignés mais avec des valeurs erronées<br />15:46:40.342321, <strong>TM_LFR_HK</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: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=30, (PACKET_SEQUENCE_CONTROL=0xc01e), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000002031f4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: OFF = 0, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0, SY_LFR_SW_VERSION_N1=3, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=3, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=68, HK_LFR_CPU_LOAD=0.392156862745, HK_LFR_CPU_LOAD_MAX=1.96078431373, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_Q_SD_FIFO_SIZE_MAX=1, HK_LFR_Q_SD_FIFO_SIZE=50, HK_LFR_Q_RV_FIFO_SIZE_MAX=1, HK_LFR_Q_RV_FIFO_SIZE=10, HK_LFR_Q_P0_FIFO_SIZE_MAX=0, HK_LFR_Q_P0_FIFO_SIZE=10, HK_LFR_Q_P1_FIFO_SIZE_MAX=0, HK_LFR_Q_P1_FIFO_SIZE=10, HK_LFR_Q_P2_FIFO_SIZE_MAX=0, HK_LFR_Q_P2_FIFO_SIZE=5, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=3, HK_LFR_REJ_TC_CNT=4, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=19, HK_LFR_LAST_EXE_TC_TIME=0x8000002024d5, <strong>HK_LFR_LAST_REJ_TC_ID=0x1cb5, HK_LFR_LAST_REJ_TC_TYPE=19</strong>, HK_LFR_LAST_REJ_TC_SUBTYPE=13,</p>
<p>Les tests effectués sur les versions 3.0.0.4, 3.0.0.8 montrent le même bug</p>
<p>les tests effectués sur l'EQM en R2 sont corrects (voir /home/validation/data/R2-EQM/2.0.2.3/SVS-0003/2015_05_25-10_26_57-Detail.txt).</p>
<p>ATTENTION<br />---------<br />Il faut egalement vérifier le comportement des autres TM_LFR_TC_EXE_xxxx<br />comme TM_LFR_TC_EXE_INCONSISTENT car TM_LFR_TC_EXE_NOT_IMPLEMENTED et TM_LFR_TC_EXE_NOT_ERROR ne peuvent etre testées.<br />Contexte du test<br />----------------<br />FSW 3.0.0.3 ou 3.0.0.8<br />VHDL 1.1.83 (_c car chgt de contrainte sur timing) ou 1.1.88<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p>
LFR-FSW - Bug #247 (Closed): Le champ TIME des TM (Cuc) reste à 0x800000000001
https://hephaistos.lpp.polytechnique.fr/redmine/issues/247
2014-10-15T11:32:19Z
Veronique bouzid
<p>Suite à la modification de Paul (Target logical ID = 0x20) pour utiliser la STarDundee en mode routeur<br />le champ TIME des TM_LFR reste poistionnée à la valeur suivante 0x800000000001.</p>
<p>Les fichiers de log sont dans /home/validation et commencent par 2014_10_15-11_34_38.<br />Le script utilisé est /home/validation/SCRIPT/just_normal_mode.py.</p>
<p>Contexte de test<br />LFR_FSW_PATH = /opt/LFR-FSW/2.0.1.1/fsw<br />Bridge selection = StarDundee<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520</p>
<p>Carte EM.</p>
LFR-FSW - Bug #182 (Closed): [JIRA] (RPWMEB-283) The content of the PA_LFR_ACQUISITION_TIME ...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/182
2014-07-09T08:39:49Z
Veronique 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 #177 (Closed): EM : Envoi TC_LFR_LOAD_SBMx_PARAM est interdit en mode SBM1 et SBM2
https://hephaistos.lpp.polytechnique.fr/redmine/issues/177
2014-06-20T07:43:37Z
Veronique bouzid
<p>EN mode SBM1 et SBM2, on ne peut envoyer de TC_LFR_LOAD_SBM1_PARAM et TC_LFR_LOAD_SBM2_PARAM.<br />Gérald a décrit un tableau dans le requirement REQ-LFR-SRS-5207_Ed1 qui récapitule<br />ce que les TC autorisées en fct du mode de LFR et celui du DAS.</p>
<p>--> Il faut donc générer des TM_LFR_TC_EXE_NOT_EXECUTABLE au lieu des TM_LFR_TC_EXE_SUCCESS<br />Voici les traces<br />en SBM1<br />on ne doit pas accepter de changer les parametres du SBM2<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:30.394448, TM_LFR_HK, HK_LFR_MODE: SBM1 = 3<br />14:21:30.803258, TC_LFR_LOAD_SBM2_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=9018, (PACKET_SEQUENCE_CONTROL=0xe33a), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM2_PARAMETERS = 27, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S2_BP_P0 = 1, SY_LFR_S2_BP_P1 = 5, CRC = 0x76fa</p>
<p>14:21:30.894486, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=111, (PACKET_SEQUENCE_CONTROL=0xc06f), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001cbbc3, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe33a</p>
<p>on ne doit pas accepter de changer les parametres du SBM1<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:33.294332, TM_LFR_HK, HK_LFR_MODE: SBM2 = 4<br />14:21:33.697692, TC_LFR_LOAD_SBM1_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6413, (PACKET_SEQUENCE_CONTROL=0xd90d), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM1_PARAMETERS = 25, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S1_BP_P0 = 0.25(s), SY_LFR_S1_BP_P1 = 1(s), CRC = 0xa7e5</p>
<p>14:21:33.794294, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=121, (PACKET_SEQUENCE_CONTROL=0xc079), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001f9e39, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd90d</p>
<hr />
<p>Contexte:<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: EM_1.1.23<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.11 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0007<br />le fichierd'analyse est /home/validation/data/R2/SVS-0007/2014_06_19-14_21_35-Detail.txt</p>
LFR-FSW - Bug #166 (Closed): PACKET LENGTH erroné pour TM_LFR_SCIENCE_BURST_BP1_F1 et TM_LFR_SCIE...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/166
2014-06-10T06:15:20Z
Veronique bouzid
<p>EN analysant le fichier 2014_06_05-12_11_54-Detail.txt correspondant au test<br />SVS-0090/generate_science_all_modes.py<br />2 pbs sur le parametre PACKET LENGTH, la longueur du packet de telemetry ne correspond pas au champ contenu dans PACKET_LENGTH</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, 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=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, 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=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>.....</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, 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=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, 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=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>,</p>
<p>Ce probleme est présent sur d'autres tests (vu egalement sur 1.0.0.6)</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 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.7 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N <strong>XX</strong>.</p>