LFR-FSW: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012021-12-08T12:19:31ZRedmine
Redmine Support #3914 (Stalled): Question sur la dernière matrice des KCOEFF...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39142021-12-08T12:19:31Zbruno katra
<p>Dans calibration_matrices.c, lors de l'init des matrices KCOEFF par défaut :</p>
<p>Est-il normal que la dernière matrice pour F0 par exemple donc celle du bin 104 soit une matrice nulle (ne contient que 0.0f)?</p> 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> 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> Support #990 (Closed): TC_LFR_LOAD_FILTER_PAR bugshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9902017-03-20T07:29:57Zpaul leroy
<p>Les bugs <a class="issue tracker-1 status-5 priority-5 priority-highest closed" title="Bug: FFT retirée alors que en dehors du TBAD (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/984">#984</a>, <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: Mauvais nombre de FFT retiré lors du filtrage PAS (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/978">#978</a> et <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: TC_LFR_LOAD_FILTER_PAR : filtrage erronée en cas de TBAD ou SHIFT non entier. (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/988">#988</a> sont liés.<br />Serait-il possible de tester la version du soft jointe, qui est une 3-2-0-5 mise à jour au niveau de la gestion de TC_LFR_LOAD_FILTER_PAR? En commençant par le cas nominal si possible.<br />J'ai effectivement trouvé un bug sur la gestion des tbad et shift non entiers, c'est normalement corrigé.<br />Pour le cas où tbad=0, j'ai fait une modif également.</p> Support #979 (Closed): Mise à jour SRS et SVS et UM https://hephaistos.lpp.polytechnique.fr/redmine/issues/9792017-03-15T11:31:08ZVeronique bouzid
<p>Mettre à jour les documents pour expliquer comment les verifications sont effectuées sur certains parametres de la TC_LFR_LOAD_FILTER_PAR dont voici la liste:<br />SY_LFR_PAS_FILTER_MODULUS<br />SY_LFR_PAS_FILTER_TBAD<br />SY_LFR_PAS_FILTER_OFFSET<br />SY_LFR_PAS_FILTER_SHIFT</p>
<p>Sur une TC_LFR_LOAD_FILTER_PAR, les tests effectués lors de l acceptage stage sont en autres<br />1- Tester individuellement les parametres<br />SY_LFR_PAS_FILTER_MODULUS = [4,8]<br />SY_LFR_PAS_FILTER_TBAD = [0.0,4.0]<br />SY_LFR_PAS_FILTER_OFFSET= [0,7]<br />SY_LFR_PAS_FILTER_SHIFT= [0.0, 1.0]</p>
<blockquote>
<p>Fait Dans SRS 2.1 +SUM 1.4</p>
</blockquote>
<p>2- Vérifier la cohérence entre ses parametres<br /><del>SY_LFR_PAS_FILTER_MODULUS <strong><=</strong> SY_LFR_PAS_FILTER_TBAD + SY_LFR_PAS_FILTER_OFFSET + SY_LFR_PAS_FILTER_SHIFT</del><br />Modif suite à discussion avec Thomas et entretien téléphonique avec Paul le 20/03/2017 : le modulus étant déterministe depuis le 1/1/2000, la formule précédente ne permettait pas de couvrir une perturbation à cheval sur 2 modulus (TC inconsistent). La nouvelle formule validée par Thomas et Paul :<br />OFFSET + SHIFT < MODULUS</p>
<p>Si cette regle n est pas vérifiée, une TM_LFR_TC_EXE_INCONSISTENT sera générée en indiquant que le paramètre erroné est SY_LFR_PAS_FILTER_MODULUS , en renseignant la position = 12 et la valeur contenue = 4 ( qui est une valeur dans le domaine de définition)<br />PA_RPW_BYTE_POSITION=12, PA_RPW_RCV_VALUE=4</p>
> Fait Dans SRS 2.1+SUM 1.4
<p>Ici un exemple<br />On envoie une TC-LOAD_FILTER_PAR avec des parametres individuellement corrects<br />SY_LFR_PAS_FILTER_MODULUS=4<br />SY_LFR_PAS_FILTER_TBAD=3.1<br />SY_LFR_PAS_FILTER_OFFSET=0<br />SY_LFR_PAS_FILTER_SHIFT=1.0</p>
<p>1:27:26.435944, <strong>TC_LFR_LOAD_FILTER_PAR</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=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=85, 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: LOAD_FILTER_PAR = 97, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0x0, DOE_SPARE=0x0, SY_LFR_PAS_FILTER_ENABLED_D: ENABLED = 1, <strong>SY_LFR_PAS_FILTER_MODULUS=4, SY_LFR_PAS_FILTER_TBAD=1078355558, SY_LFR_PAS_FILTER_OFFSET=0, SY_LFR_PAS_FILTER_SHIFT=1065353216, SY_LFR_PAS_FILTER_DELTA_F=1027101164, SY_LFR_RW1_K1=0x3f800000</strong>,</p>
<p>11:27:26.445925, <strong>TM_LFR_TC_EXE_INCONSISTENT</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=8, (PACKET_SEQUENCE_CONTROL=0xc008), 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=0x8000001727ef, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, <strong>PA_RPW_BYTE_POSITION=12, PA_RPW_RCV_VALUE=4</strong></p>
<p>==> N'est plus vrai depuis la modif de Paul sur la cohérence des paramètres.</p>
<p>Les parametres sont testés même si champ SY_LFR_PAS_FILTER_ENABLED_D = DISABLE.<br />> Fait Dans SRS 2.1+SUM 1.4</p>
<p>Ajouter un paragraphe sur le merge des fbins masks + rw masks<br />> Fait Dans SRS 2.1+SUM 1.4</p>
<p><strong>Aouter un paragraphe su rla caractérisation du filtre IIR pour tâche AVGV moyennage HK (déphasage + perte 12% amplitude)</strong></p> 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> Support #868 (Closed): Question sur merge_fbins_maskshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8682016-12-29T12:04:44ZVeronique bouzid
<p>Peux-tu expliquer le pourquoi de cette fonction?</p> Support #714 (Stalled): Parametrage TCPhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7142016-06-27T14:05:27ZVeronique bouzid
<p>suite au transfert du disque de pc-faust9 dans pc-solar3, la valeur par défaut du champ Server IP dans l onglet TCP server du SpwPlugin0<br />est positionné à une mauvaise valeur, idem dans l onglet connection du LFRControlPlugin0)<br />Il faut donc mettre dans les scripts d'init les 2 lignes suivantes<br />SpwPlugin0.TCPServerSetIP("127.0.0.1")<br />LFRControlPlugin0.SetSpwServerIP(127,0,0,1)<br />indiquant que l'on utilise l'adresse ip du localhost.</p>
<p>Il faut chercher pourquoi Soc veut utiliser l'adresse virtuelle de la machine<br />virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500<br /> inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255<br /> ether 52:54:00:54:9d:28 txqueuelen 1000 (Ethernet)<br /> RX packets 0 bytes 0 (0.0 B)<br /> RX errors 0 dropped 0 overruns 0 frame 0<br /> TX packets 0 bytes 0 (0.0 B)<br /> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0</p> Support #706 (Closed): Pb aux bornes des intervales pour le rejet des fréquences polluées par les...https://hephaistos.lpp.polytechnique.fr/redmine/issues/7062016-06-16T05:37:47Zpaul leroy
<p>Mail Gérald Saule 09/06/2016</p>
<p>j'ai une question au sujet de la prise en compte du "LFR filtering of SC reaction wheel emissions". Cela recoupe le point 1 de la note <a class="external" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/691#note-3">https://hephaistos.lpp.polytechnique.fr/redmine/issues/691#note-3</a> d'Alexis.<br />Afin de voir quelle convention tu as prise, peux-tu me décrire comment se comportera le FSW dans les deux situations suivantes représentatives (sachant que 14.50Hz est à l'intersection des deux "LFR_BP2_F0/LFR_BP2_AUTO_F0" de TM_LFR_SCIENCE_NORMAL_BP2_F2 pour N=0 et N=1):</p>
<p>*Pour CP_RPW_SC_RWn_Fm=14.475Hz: les bornes de l'intervale pollué par l'emission RW sont CP_RPW_SC_RWn_Fm+/-SY_LFR_SC_RW_DELTA_F (=14.45 et 14.50Hz). Le LFR_BP2_AUTO_F0 (de TM_LFR_SCIENCE_NORMAL_BP2_F2) pour N=1 va t'il intégrer dans sa moyenne le bin de rang 15 (couvrant [14.5;15.5]) ?</p>
<p>*Pour CP_RPW_SC_RWn_Fm=14.525Hz : les bornes de l'intervale pollué par l'emission RW sont CP_RPW_SC_RWn_Fm+/-SY_LFR_SC_RW_DELTA_F (=14.50 et 14.55Hz). Le LFR_BP2_AUTO_F0 (de TM_LFR_SCIENCE_NORMAL_BP2_F2) pour N=0 va t'il intégrer dans sa moyenne le bin de rang 14 (couvrant [13.5;14.5]) ?</p>
<p>NB: Avec SY_LFR_SC_RW_DELTA_F=0.025 Hz (default value), et CP_RPW_SC_RW[1-4]_F[1-2]_FLAG=enable.</p> Support #656 (Closed): SHow to validate HK_LFR_VHDL_SM fieldhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6562016-03-09T13:51:37ZVeronique bouzid
<p>En analysant le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0078/update_time_cnt.py</p>
<p>Le champ HK_LFR_VHDL_SM est mis à jour par moment.</p>
<p>Ici le rappel de la description de HK_LFR_VHDL_SM founrnie par Paul et extraite de la doc de Jean-Christophe<br />HK_LFR_VHDL_SM 4 bits extraits du registre SPECTRAL_ MATRIX_STATUS du VHDL.<br />bit3 input_fifo_write(2)<br />bit2 input_fifo_write(1)<br />bit1 input_fifo_write(0)<br />bit0 buffer_full</p>
<p>Durant l script, voici les valeurs observées:<br />Debut test<br />10:20:47.301929, TC_LFR_ENTER_MODE (CP_LFR_MODE=0)<br />10:20:47.479462, TM_LFR_HK, TIME=0x8000000848b9 ,HK_LFR_MODE: STANDBY = 0, HK_LFR_VHDL_SM=0<br />10:20:56.721585, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)<br />10:20:56.752519, TM_LFR_TC_EXE_SUCCESS, TIME=0x800000118ec2<br /><strong>10:20:57.479062, TM_LFR_HK, TIME=0x8000001248ba, HK_LFR_MODE: NORMAL = 1, HK_LFR_VHDL_SM=1 --> expliquez</strong><br />----<br />10:21:06.153222, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />10:21:06.192273, TM_LFR_TC_EXE_SUCCESS, TIME=0x8000001aff2a<br />----<br />10:21:15.592969, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />10:21:15.637686, TM_LFR_TC_EXE_SUCCESS, TIME=0x800000247131<br />----<br />10:21:25.038379, TC_LFR_ENTER_MODE (CP_LFR_MODE=4)<br />10:21:25.091221, TM_LFR_TC_EXE_SUCCESS, TIME=0x8000002de58e<br />----<br />10:21:34.491944, TC_LFR_ENTER_MODE (CP_LFR_MODE=0)<br /><strong>10:21:35.479176, TM_LFR_HK, TIME=0x8000003848b9, , HK_LFR_MODE: STANDBY = 0,, HK_LFR_VHDL_SM=2 --> expliquez</strong></p>
<p>Y a t il un interet à surveiller les valeurs prises par ce champ et quelles infos peut on en tirer?</p>
<p>Les fichiers de test (2016_02_19-10_21_39*) se trouvent dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0078.</p>
<p>Contexte du test<br />----------------------<br />LFR_FSW_PATH = /opt/LFR/LFR-FSW/3.0.0.22/fsw<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481</p> Support #634 (Closed): SEction HK_LFR_STATUS_WORD in TM_LFR_HKhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6342016-02-23T13:56:33ZVeronique bouzid
<p>Peux-tu me confirmer pour chacun des champs ci-dessous* si tu les remplis et avec quelles valeurs.*</p>
<p>HK_LFR_DPU_SPW_LINK_STATE : <br />je n ai observé que la valeur RUN.</p>
<p>HK_LFR_RESET_CAUSE: <br />je n ai observé que la valeur POWER_ON d'ailleurs je n ai trouvé qu'un seul appel à la fonction set_hk_lfr_reset_cause</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />Timegen 0.0.0.1<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> Support #627 (Closed): Commutation immediatehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6272016-02-14T09:10:52ZVeronique 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> Support #626 (Closed): Lost TM_LFR_HK in 3.0.0.22 https://hephaistos.lpp.polytechnique.fr/redmine/issues/6262016-02-13T15:47:08ZVeronique bouzid
<p>Suite au lancement du test /opt/VALIDATION_R3/test_mode_SBMx_12h.py</p>
<p>On observe la perte d'une TM_LFR_HK au début du test .<br />2016 2 13 11:48:53:509 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e51d4a2 870c<br />2016 2 13 11:48:53:513 TM_LFR_TC_EXE_SUCCESS time = 0x 1e51d4a2 8d55<br />2016 2 13 11:48:54:343 TM_LFR_HK time = <strong>0x 1e51d4a3 628b</strong><br />2016 2 13 11:48:55:343 TM_LFR_HK time = <strong>0x 1e51d4a6 628b</strong><br />2016 2 13 11:48:56:343 TM_LFR_HK time = 0x 1e51d4a7 628b<br />2016 2 13 11:48:57:343 TM_LFR_HK time = 0x 1e51d4a8 628a</p>
<p>Vu également sur la version 3.0.0.20.<br />3.0.0.20 avec timegen (2016_02_10_17_15_12_packet_log.data)<br />2016 2 10 17:15:12:504 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e4e2c9e f521<br />2016 2 10 17:15:12:507 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e f52e<br />2016 2 10 17:15:12:515 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e f53d<br />2016 2 10 17:15:12:539 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e fc14<br />2016 2 10 17:15:12:573 TM_LFR_HK time = 0x 1e4e2c9f 6b0<br />2016 2 10 17:15:13:554 TM_LFR_HK <strong>time = 0x 1e4e2ca1 1ee</strong><br />2016 2 10 17:15:14:554 TM_LFR_HK time = 0x 1e4e2ca2 1ee<br />2016 2 10 17:15:15:554 TM_LFR_HK time = 0x 1e4e2ca3 1ed<br />2016 2 10 17:15:16:554 TM_LFR_HK time = 0x 1e4e2ca4 1ed</p>
<p>Si on avait la decommutation des HK, on pourrait voir si le SEQUENCE_CNT du packet est coherent avec une perte de paquet.</p>
<p>J'ai analysé les autres tests et c'est la deuxieme ois que je le vois mais on a peu de tests avec timegen pour comparer.</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />EM AVEC Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> Support #607 (Closed): medium Criticity : How can we do ithttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6072016-02-03T15:40:56ZVeronique bouzid
<p>Pour valider les erreurs classées de type medium criticity:<br />comment fait on?</p>
<p>HK_LFR_DPU_SPW_EARLY_EOP<br />HK_LFR_DPU_SPW_INVALID_ADDR<br />HK_LFR_DPU_SPW_EEP<br />HK_LFR_DPU_SPW_RX_TOO_BIG<br />HK_LFR_BUFFER_DPU_TC_FIFO<br />HK_LFR_BUFFER_DPU_TM_FIFO<br />HK_LFR_AHB_UNCORRECTABLE</p> Support #596 (Stalled): Mise à jour logiciel LFR-SGSEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5962016-01-27T07:47:27ZVeronique bouzid
<p>Il faudrait mettre à jour le logiciel LFR-SGSE pour visualiser sur l'interface HK les nouveaux champs<br />implémentés.</p>