INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-01-19T10:26:55ZRedmine
Redmine LFR-FSW - Bug #4012 (Closed): TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40122023-01-19T10:26:55ZVeronique bouzid
<p>Dans le test /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0086/load_kcoeff_with_dump_v3-3.py</p>
<p>l'envoi d'un TC_LFR_LOAD_KCOEFFICIENTS avec KCOEFF_FREQ = 0, KCOEFF_1 = 1065353216 à KCOEFF_32 = 1065353216<br /> ne doit pas modifier les KCOEFF contenus dans la TM_LFR_KCOEFFICIENTS_DUMP.</p>
<p>Extrait</p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000d233f, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1065353216, SY_LFR_KCOEFF_2=1065353216, SY_LFR_KCOEFF_3=1065353216, SY_LFR_KCOEFF_4=1065353216, SY_LFR_KCOEFF_5=1065353216, SY_LFR_KCOEFF_6=1065353216, SY_LFR_KCOEFF_7=1065353216, SY_LFR_KCOEFF_8=1065353216, SY_LFR_KCOEFF_9=1065353216, SY_LFR_KCOEFF_10=1065353216, SY_LFR_KCOEFF_11=1065353216, SY_LFR_KCOEFF_12=1065353216, SY_LFR_KCOEFF_13=1065353216, SY_LFR_KCOEFF_14=1065353216, SY_LFR_KCOEFF_15=1065353216, SY_LFR_KCOEFF_16=1065353216, SY_LFR_KCOEFF_17=1065353216, SY_LFR_KCOEFF_18=1065353216, SY_LFR_KCOEFF_19=1065353216, SY_LFR_KCOEFF_20=1065353216, SY_LFR_KCOEFF_21=1065353216, SY_LFR_KCOEFF_22=1065353216, SY_LFR_KCOEFF_23=1065353216, SY_LFR_KCOEFF_24=1065353216, SY_LFR_KCOEFF_25=1065353216, SY_LFR_KCOEFF_26=1065353216, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p>On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur modifiée par la TC_LFR_LOAD_KCOEFFICIENTS_alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).</p>
<p><ins>Ici les valeurs de référence récupérées au boot</ins></p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1050859893, SY_LFR_KCOEFF_2=1051774863, SY_LFR_KCOEFF_3=3199048410, SY_LFR_KCOEFF_4=3199675526, SY_LFR_KCOEFF_5=1048105208, SY_LFR_KCOEFF_6=1049731468, SY_LFR_KCOEFF_7=3199884855, SY_LFR_KCOEFF_8=3201093691, SY_LFR_KCOEFF_9=1002946415, SY_LFR_KCOEFF_10=993270132, SY_LFR_KCOEFF_11=1052396741, SY_LFR_KCOEFF_12=1051678457, SY_LFR_KCOEFF_13=3193633745, SY_LFR_KCOEFF_14=3195990147, SY_LFR_KCOEFF_15=3202344225, SY_LFR_KCOEFF_16=3204016481, SY_LFR_KCOEFF_17=3191761623, SY_LFR_KCOEFF_18=3194781000, SY_LFR_KCOEFF_19=0, SY_LFR_KCOEFF_20=2147483648, SY_LFR_KCOEFF_21=3164388996, SY_LFR_KCOEFF_22=3169957665, SY_LFR_KCOEFF_23=3164388996, SY_LFR_KCOEFF_24=3169957665, SY_LFR_KCOEFF_25=3156000388, SY_LFR_KCOEFF_26=3161569057, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p><strong>QUESTION<br />----------------<br />Est ce un bug ou bien le comportement attendu?</strong></p>
<p>Contexte du test<br />----------------------<br />FSW 3.3.0.11 et 3.3.0.12<br />VHDL 1.1.91<br />EM2 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #2134 (Stalled): Emission d'une raie à 96Hz par LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/21342017-10-11T09:09:58ZAlexis Jeandet
<p>Pendant les tests EMC, il a été mesuré une raie à 96Hz émise par LFR.<br />Après quelques investigations, ça s'explique par le fait que la consomation du FPGA entre le moment ou le CPU est en POWERDOWN et le moment ou il travaille est assez différente. De plus 96Hz correspond à la fréquence des interruptions pour les ASM à F0.<br />Une première tentative de mitigation en ajoutant une tache qui consomme du CPU en background a permis de baisser les niveaux d'émission mais c'est pas encore suffisant.<br />Il faut essayer de monter encore un peu la conso dans cette tache idle en utilisant la FPU par exemple.</p>
<ul>
<li><a href="https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/INSTRUMENTATION/USERS/JEANDET/LFR_FSW/changeset/fc82b08705ba9931880e4e57a76b1bb1ffa1e28e" class="external">Commit actuel</a></li>
<li><a href="https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/INSTRUMENTATION/USERS/JEANDET/SOLO_LFR_Notebooks/files/ea8683773e3816b28b499a7520bdfde53353a82a/LFR_CPU_POWERDOWN_EFFECT/LFR_CPU_POWERDOWN_EFFECT.ipynb" class="external">Analyse de l'effet du powerdown</a></li>
</ul> LFR-FSW - Bug #1029 (Stalled): La tâche AVGV semble s'arrêter lorsque l'on repasse en STDBY sur l...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10292017-03-27T14:15:21Zbruno katra
<p>La courbe ci-dessous montre les moyennes dans les HK avec un signal de 0.1Hz sur V et 5Hz sur E1 -3/3V en STANDBY puis passage en NORMAL pendant 10s et repassage en STANDBY (on voit d'ailleurs le bug <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 have amazing values when a TC_LFR_ENTER_MODE is... (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/955">#955</a> de Véro).</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2192/FLOWCHART01.png" alt="" /></p>
<p>Ceci est confirmé en regardant les valeurs dans les HK :<br />[LFR@pc-solar1 3.2.0.9]$ more hk<br /> V E1 E2<br /> 431 434 379 > STDBY<br /> 432 433 380>.....<br /> 430 433 380<br /> 430 433 380<br /> 432 434 379<br /> 431 434 379<br /> 430 435 380<br /> 431 434 380<br /> 431 434 380<br /> 430 434 380<br /> 432 433 379<br /> 431 436 380<br /> 431 434 380 <br /> 8279 1271 381 > NORMAL<br /> 22638 418 377<br /> 27125 409 376<br /> 21361 411 377<br /> 7575 411 377<br /> -8947 410 378<br /> -21935 410 378<br /> -26425 410 378<br /> -20669 410 377<br /> -6895 410 377<br /> 9642 410 378<br /> 22631 410 377> STDBY<br /> 540 415 338 <br /> 433 435 377<br /> 430 434 379<br /> 432 434 379<br /> 430 435 379</p>
<p>SSS-CP-EQS-526 ne stipule pas que la moyenne n'est faite qu'en mode SCIENCE. Nous avions compris que le moyennage est tout le temps actif (y compris en BURST et STANDBY où il n'y a pas de produits F3)</p> LFR-FSW - Bug #981 (Closed): TC_LFR_LOAD_FILTER_PAR not acknowledgedhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9812017-03-16T09:19:03ZVeronique 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 #867 (Closed): Fonction setFBinMask: Calcul masque erroné https://hephaistos.lpp.polytechnique.fr/redmine/issues/8672016-12-29T11:44:23ZVeronique 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éehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8652016-12-29T10:56:07ZVeronique 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 errorhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6572016-03-09T14:28:44ZVeronique 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 - Bug #247 (Closed): Le champ TIME des TM (Cuc) reste à 0x800000000001https://hephaistos.lpp.polytechnique.fr/redmine/issues/2472014-10-15T11:32:19ZVeronique 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 #177 (Closed): EM : Envoi TC_LFR_LOAD_SBMx_PARAM est interdit en mode SBM1 et SBM2 https://hephaistos.lpp.polytechnique.fr/redmine/issues/1772014-06-20T07:43:37ZVeronique 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 #171 (Closed): TM_LFR_PARAMETER_DUMP et TM_LFR_HK est reçue avec CONTINUATION_PACKE...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1712014-06-16T12:56:47Zbruno katra
<p>D'après SSS-CP-EQS-415 : le segmentation grouping flag doit toujours être placé à 3 (standalone).<br />Ce n'est pas le cas pour TM_LFR_PARAMETER_DUMP et TM_LFR_HK</p>
<p>14:29:47.876692, TM_LFR_PARAMETER_DUMP, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: DUMP = 9, (PACKET_ID=0xcc9), <strong>SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0,</strong></p>
<p>14:29:47.325072, TM_LFR_HK, 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), <strong>SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0,</strong></p>
<p>---------------------------------<br />Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065<br />Soft:1.0.0.9b (variante sur carte finale)</p>
<p>TEST CASE = SVS-0065<br />Req = SSS-CP-EQS-415</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue3_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</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/1662014-06-10T06:15:20ZVeronique 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> LFR-FSW - Bug #117 (Closed): Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/1172014-04-09T14:59:58ZGerald Saule
<p>Le champ SEQUENCE_CNT des TM correspond au nombre de TM pour chaque couple (PACKET_ID,DESTINATION_ID).<br />Il y a un pb d'homogénéïté lors de l'implémentation de cette affectation:<br />-Pour PACKET_ID=0xcfc et DESTINATION_ID: GROUND = 0 (TM_LFR_SCIENCE_SBM1_CWF_F1), la premier paquet est en SEQUENCE_CNT=0.<br />-Pour les autres couples, le premier paquet est en SEQUENCE_CNT=1.</p>
<p><strong>Les SEQUENCE_CNT doivent commencer à 0 dès la première TM (cf. mail Philippe Plasson 4/06/2014)</strong></p>
<p>D'autre part, il y a aussi un pb sur le pivot pour TM_LFR_SCIENCE_SBM1_CWF_F1 (PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0): après SEQUENCE_CNT=255, on repasse malheureusement à SEQUENCE_CNT=0.</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 III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.9<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.5 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0019<br />Req = SSS-CP-FS-590</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #97 (Rejected): TM_LFR_HK: sauts de HK_LFR_DPU_SPW_PKT_SENT_CNThttps://hephaistos.lpp.polytechnique.fr/redmine/issues/972014-03-19T12:04:35ZGerald Saule
<p>Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.<br />Les traces obtenues sont:</p>
<blockquote>
<p>18:38:27.989082, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=1728, HK_LFR_MODE: STANDBY = 0</p>
<p>DECONNECTION/RECONNECTION</p>
<p>18:38:30.59011, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=*4003*; exp=1729 , HK_LFR_MODE: STANDBY = 0</p>
</blockquote>
<p>Le pb porte sur le saut inaproprié de la valeur de HK_LFR_DPU_SPW_PKT_SENT_CNT.<br />Notons que la déconnexion se traduit ici par une absence de TM pendant 2.6s, ce qui laisse présentir que le FSW a identifié une perte du lien confirmée pendant SY_LFR_DPU_CONNECT_TIMEOUT (=1000ms); une mise en oeuvre des SSS-CP-EQS-153/154/155 étant prévisible.</p>
<p>Ce test montre aussi d'autres irrégulariés de HK_LFR_DPU_SPW_PKT_SENT_CNT: davantage compréhensibles, elles sont tracées par l'issue "TM_LFR_HK: HK_LFR_DPU_SPW_PKT_SENT_CNT périmé".</p>
<p><ins>Contexte:</ins></p>
<p>LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.15<br />Soft: 1.0.0.1 (variante sur carte finale)<br />Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0061</p>
<p>RPW-SYS-IDB-00067-LES_Issue1_Rev8<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> VHDLib - Bug #96 (Rejected): DMA latency to access External memoryhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/962014-03-18T09:18:41ZJean-Christophe Pellion
<p>1- Verify than there is too waitstate access during a Memory Burst Access<br />2- Try others configurations to limit this latency ...</p> LFR-FSW - Bug #57 (Closed): TC_LFR_LOAD_NORMAL_PAR renvoie TM_LFR_TC_EXE_NOT_IMPLEMENTED si SY_LF...https://hephaistos.lpp.polytechnique.fr/redmine/issues/572014-02-19T16:31:00ZGerald Saule
<p>Pour TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L affecté conformément à Bug #816 (SY_LFR_N_SWF_L: >=16, multiple de 16, <= 2048), mais différent de la valeur par défaut (2048).<br />L'acquittement retourne TM_LFR_TC_EXE_NOT_IMPLEMENTED (excepté en NORMAL).</p>
<blockquote>
<p>16:44:52.151797, TC_LFR_LOAD_NORMAL_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=830, (PACKET_SEQUENCE_CONTROL=0xc33e), PACKET_LENGTH=15, 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_NORMAL_PARAMETERS_1 = 13, SOURCE_ID: TC_SEQUENCES = 111, SY_LFR_N_SWF_L = 16, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 3600(s), SY_LFR_N_BP_P0 = 4(s), SY_LFR_N_BP_P1 = 20(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3 = 1, SPARE=0x0, CRC = 0x4b87</p>
<p>16:44:52.15462, TM_LFR_TC_EXE_NOT_IMPLEMENTED, 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=228, (PACKET_SEQUENCE_CONTROL=0xc0e4), PACKET_LENGTH=17, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: TC_SEQUENCES = 111, TIME=0x80016c046b62, PA_RPW_TC_FAILURE_CODE: FUNCT_NOT_IMPL = 42002, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc33e, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=13</p>
</blockquote>
<p>(Cette issue reprend Bug #835 de pc-instru)</p>
<p>Contexte:</p>
<p>LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.1 (variante sur carte finale)<br />Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001_step03</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>