Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-01-24T11:00:35ZRedmine
Redmine LFR-FSW - Bug #4015 (Closed): HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteu...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40152023-01-24T11:00:35ZVeronique bouzid
<p>Le test SVS-0026 doit vérifier le requirement suivant<br />All the counters (error counter, packet counter, etc) managed by LFR FSW shall restart at 0 when tehy reached their maximun value.</p>
<p>Le script qui teste le compteur HK_LFR_DPU_SPW_RX_TOO_BIG envoie 257 Tc générant une erreur. Le compteur valide bien le requirement et on voit parfaitement le passage à zero.</p>
<p>Un autre compteur nommé HK_LFR_ME_CNT comptabilise les erreurs de type medium. HK_LFR_DPU_SPW_RX_TOO_BIG fait partie de ce type d erreur et donc on s'attend à la fin du test à obtenir<br />HK_LFR_ME_CNT=257. Ce n est pas le cas il manque 1.</p>
<p>Ici un extrait des valeurs de ces 2 compteurs (fichir verif_count.txt)<br />11:47:45.222921 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=0 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />11:47:46.242728 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:47.222395 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:48.223832 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:49.222892 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:50.223058 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=2 HK_LFR_DPU_SPW_RX_TOO_BIG=2<br />----</p>
<p>12:04:48.226406 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=255<br />12:04:49.225973 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0</strong><br />12:04:50.225914 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:51.226438 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:52.225955 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:53.225879 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:54.22646 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:55.225976 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:56.225969 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:57.22624 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:58.226003 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:59.226005 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:00.226468 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:01.226032 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1</strong></p>
<p>On voit la parfaite égalité des 2 compteurs excepté après le wrap de HK_LFR_DPU_SPW_RX_TOO_BIG.<br />Le script joué se nomme /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_rx_too_big_cnt_wrap.py et les fichiers de test sont dans<br />/home/validation/data/R3.3/3.3.0.11/1.1.91/SVS-0026/TESTS/check_rx_too_big_cnt_wrap</p>
<p>Contexte du test<br />---------------------<br />FSW 3.3.0.11<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />StarDundee</p>
<p><strong>ATTENTION<br />Il se peut que ce bug soit applicable également à la gestion du compteur d'erreur HK_LFR_LE_CNT.</strong></p> LFR-FSW - Bug #4012 (Closed): TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40122023-01-19T10:26:55ZVeronique bouzid
<p>Dans le test /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0086/load_kcoeff_with_dump_v3-3.py</p>
<p>l'envoi d'un TC_LFR_LOAD_KCOEFFICIENTS avec KCOEFF_FREQ = 0, KCOEFF_1 = 1065353216 à KCOEFF_32 = 1065353216<br /> ne doit pas modifier les KCOEFF contenus dans la TM_LFR_KCOEFFICIENTS_DUMP.</p>
<p>Extrait</p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000d233f, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1065353216, SY_LFR_KCOEFF_2=1065353216, SY_LFR_KCOEFF_3=1065353216, SY_LFR_KCOEFF_4=1065353216, SY_LFR_KCOEFF_5=1065353216, SY_LFR_KCOEFF_6=1065353216, SY_LFR_KCOEFF_7=1065353216, SY_LFR_KCOEFF_8=1065353216, SY_LFR_KCOEFF_9=1065353216, SY_LFR_KCOEFF_10=1065353216, SY_LFR_KCOEFF_11=1065353216, SY_LFR_KCOEFF_12=1065353216, SY_LFR_KCOEFF_13=1065353216, SY_LFR_KCOEFF_14=1065353216, SY_LFR_KCOEFF_15=1065353216, SY_LFR_KCOEFF_16=1065353216, SY_LFR_KCOEFF_17=1065353216, SY_LFR_KCOEFF_18=1065353216, SY_LFR_KCOEFF_19=1065353216, SY_LFR_KCOEFF_20=1065353216, SY_LFR_KCOEFF_21=1065353216, SY_LFR_KCOEFF_22=1065353216, SY_LFR_KCOEFF_23=1065353216, SY_LFR_KCOEFF_24=1065353216, SY_LFR_KCOEFF_25=1065353216, SY_LFR_KCOEFF_26=1065353216, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p>On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur modifiée par la TC_LFR_LOAD_KCOEFFICIENTS_alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).</p>
<p><ins>Ici les valeurs de référence récupérées au boot</ins></p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1050859893, SY_LFR_KCOEFF_2=1051774863, SY_LFR_KCOEFF_3=3199048410, SY_LFR_KCOEFF_4=3199675526, SY_LFR_KCOEFF_5=1048105208, SY_LFR_KCOEFF_6=1049731468, SY_LFR_KCOEFF_7=3199884855, SY_LFR_KCOEFF_8=3201093691, SY_LFR_KCOEFF_9=1002946415, SY_LFR_KCOEFF_10=993270132, SY_LFR_KCOEFF_11=1052396741, SY_LFR_KCOEFF_12=1051678457, SY_LFR_KCOEFF_13=3193633745, SY_LFR_KCOEFF_14=3195990147, SY_LFR_KCOEFF_15=3202344225, SY_LFR_KCOEFF_16=3204016481, SY_LFR_KCOEFF_17=3191761623, SY_LFR_KCOEFF_18=3194781000, SY_LFR_KCOEFF_19=0, SY_LFR_KCOEFF_20=2147483648, SY_LFR_KCOEFF_21=3164388996, SY_LFR_KCOEFF_22=3169957665, SY_LFR_KCOEFF_23=3164388996, SY_LFR_KCOEFF_24=3169957665, SY_LFR_KCOEFF_25=3156000388, SY_LFR_KCOEFF_26=3161569057, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p><strong>QUESTION<br />----------------<br />Est ce un bug ou bien le comportement attendu?</strong></p>
<p>Contexte du test<br />----------------------<br />FSW 3.3.0.11 et 3.3.0.12<br />VHDL 1.1.91<br />EM2 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #1085 (Closed): PA_RPW_BYTE_POSITION wrong into a TM_LFR_TC_EXE_INCONSISTENT on TC_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10852017-04-25T16:25:51ZVeronique bouzid
<p>Le test du parametre SY_LFR_PAS_FILTER_DELTA_F:<br />envoi d'une frequence négative (-1) = 0x BF800000 et entier 3212836864</p>
<p>08:31:38.573693, <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=15232, (PACKET_SEQUENCE_CONTROL=0xfb80), PACKET_LENGTH=85, 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_FILTER_PAR = 97, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0x0, DOE_SPARE=0x0, SY_LFR_PAS_FILTER_ENABLED_D: ENABLED = 1, SY_LFR_PAS_FILTER_MODULUS=4, SY_LFR_PAS_FILTER_TBAD=1065353216, SY_LFR_PAS_FILTER_OFFSET=0, SY_LFR_PAS_FILTER_SHIFT=1056964608, <strong>SY_LFR_PAS_FILTER_DELTA_F=3212836864,</strong> SY_LFR_RW1_K1=0x3f800000, SY_LFR_RW1_K2=0x41000000, SY_LFR_RW1_K3=0x41c00000, SY_LFR_RW1_K4=0x42400000, SY_LFR_RW2_K1=0x3f800000, SY_LFR_RW2_K2=0x41000000, SY_LFR_RW2_K3=0x41c00000, SY_LFR_RW2_K4=0x42400000, SY_LFR_RW3_K1=0x3f800000, SY_LFR_RW3_K2=0x41000000, SY_LFR_RW3_K3=0x41c00000, SY_LFR_RW3_K4=0x42400000, SY_LFR_RW4_K1=0x3f800000, SY_LFR_RW4_K2=0x41000000, SY_LFR_RW4_K3=0x41c00000, SY_LFR_RW4_K4=0x42400000, CRC = 0xffb7</p>
<p>08:31:38.580833, TM_LFR_TC_EXE_INCONSISTENT, 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=98, (PACKET_SEQUENCE_CONTROL=0xc062), 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=0x8000002cf329, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xfb80, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, PA_RPW_BYTE_POSITION=22, <strong>PA_RPW_RCV_VALUE=255</strong></p>
<p>la position du champ est correcte PA_RPW_BYTE_POSITION=22 mais la valeur devrait correspondre au Least Byte soit 00 pusique le champ complet vaut<br />0x BF800000. D'ailleurs aucun octet de vaut 255 (0xFF).</p>
<p>Les parametres suivants ont été testés et sont correctement décrits<br />SY_LFR_PAS_FILTER_MODULUS<br />08:31:26.495614, TM_LFR_TC_EXE_INCONSISTENT, TIME=0x80000020dc93, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, PA_RPW_BYTE_POSITION=12, PA_RPW_RCV_VALUE=0</p>
<p>SY_LFR_PAS_FILTER_TBAD<br />08:31:29.514696, TM_LFR_TC_EXE_INCONSISTENT, TIME=0x80000023e231, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, PA_RPW_BYTE_POSITION=13, PA_RPW_RCV_VALUE=236</p>
<p>SY_LFR_PAS_FILTER_OFFSET<br />08:31:32.536943, TM_LFR_TC_EXE_INCONSISTENT, TIME=0x80000026e7f1, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, PA_RPW_BYTE_POSITION=17, PA_RPW_RCV_VALUE=8</p>
<p>SY_LFR_PAS_FILTER_SHIFT<br />08:31:35.558894, TM_LFR_TC_EXE_INCONSISTENT, TIME=0x80000029edbd, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, PA_RPW_BYTE_POSITION=18, PA_RPW_RCV_VALUE=174</p>
<p>Envoi de SY_LFR_RW1_K1=0xbf800000 --1)<br />08:31:41.603624, TM_LFR_TC_EXE_INCONSISTENT, TIME=0x8000002ff8fd, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=97, PA_RPW_BYTE_POSITION=26, PA_RPW_RCV_VALUE=0</p>
<p>Le script utilisé est /opt/VALIDATION_R3plusplus/lfrverif/LFR_SVS/SVS-0008/tc_execution_failure_report.py.<br />Les fichiers de log (2017_04_20-08_32_02*) sont rangés dans /home/validation/data/R3++/3.2.0.15/3.1.91/SVS-0008</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> LFR-FSW - Bug #1084 (Closed): PA_RPW_BYTE_POSITION wrong into a TM_LFR_TC_EXE_INCONSISTENT on TC...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10842017-04-25T16:04:21ZVeronique bouzid
<p>Cela ressemble à un bug deja tracé (<a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: R3 *** TC_LFR_LOAD_KCOEFFICIENTS: SY_LFR_KCOEFF_FREQUENCY ne doit pas etre superieur à 35 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/426">#426</a>)<br />Sur TC_LFR_LOAD_KCOEFFICIENTS, un seul champ genere une TM_LFR_TC_EXE_INCONSISTENT, c est KCOEFF_FREQ.<br />Envoi du champ KCOEFF_FREQ = 36 pour generer l inconsistent</p>
<p>08:31:25.474498, <strong>TC_LFR_LOAD_KCOEFFICIENTS</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=7906, (PACKET_SEQUENCE_CONTROL=0xdee2), PACKET_LENGTH=135, 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_KCOEFFICIENTS = 93, SOURCE_ID: MISSION_TIMELINE = 110, <strong>KCOEFF_FREQ = 36,</strong> KCOEFF_1 = 1065353216, KCOEFF_2 = 1065353216, KCOEFF_3 = 1065353216, KCOEFF_4 = 1065353216, KCOEFF_5 = 1065353216, KCOEFF_6 = 1065353216, KCOEFF_7 = 1065353216, KCOEFF_8 = 1065353216, KCOEFF_9 = 1065353216, KCOEFF_10 = 1065353216, KCOEFF_11 = 1065353216, KCOEFF_12 = 1065353216, KCOEFF_13 = 1065353216, KCOEFF_14 = 1065353216, KCOEFF_15 = 1065353216, KCOEFF_16 = 1065353216, KCOEFF_17 = 1065353216, KCOEFF_18 = 1065353216, KCOEFF_19 = 1065353216, KCOEFF_20 = 1065353216, KCOEFF_21 = 1065353216, KCOEFF_22 = 1065353216, KCOEFF_23 = 1065353216, KCOEFF_24 = 1065353216, KCOEFF_25 = 1065353216, KCOEFF_26 = 1065353216, KCOEFF_27 = 1065353216, KCOEFF_28 = 1065353216, KCOEFF_29 = 1065353216, KCOEFF_30 = 1065353216, KCOEFF_31 = 1065353216, KCOEFF_32 = 1065353216,CRC = 0x436f</p>
<p>08:31:25.484079, <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=89, (PACKET_SEQUENCE_CONTROL=0xc059), 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=0x8000001fd995, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xdee2, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=93, <strong>PA_RPW_BYTE_POSITION=11, PA_RPW_RCV_VALUE=36</strong></p>
<p>On devrait avoir PA_RPW_BYTE_POSITION = 10 et non 11</p>
<p>J ai vérifié les autres commande de type LOAD_xxx_PAR. On met toujours le BYTE position du parametre et la valeur est l octet LSB du champ.</p>
<p>Paul, peux-tu verifier cela?</p>
<p>Le script utilisé est /opt/VALIDATION_R3plusplus/lfrverif/LFR_SVS/SVS-0008/tc_execution_failure_report.py.<br />Les fichiers de log (2017_04_20-08_32_02*) sont rangés dans /home/validation/data/R3++/3.2.0.15/3.1.91/SVS-0008</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<br />--------------</p> LFR-FSW - Bug #1005 (Closed): HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3 , HK_LFR_SC_E2_F3 see a differentn...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10052017-03-21T08:56:12ZVeronique bouzid
<p>Pourquoi les valeurs observées sur les champs suivants ne montrent plus le bruit de fond qui oscillait autour de 500 counts dans la version 3.2.0.3.<br />Le test a été fait sur EM1 sans les harnais.</p>
<p>Le LFR SGSE montrent des valeurs <br />v_f3 autour de -20000 <br />e1_f3 autour de -21500<br />e2_f3 autour de 31500</p>
<p>mes logs montrent sur la derniere HK en standby<br />HK_LFR_SC_V_F3= 46096 --> en hexa B410 car on lit les 16 bits<br />HK_LFR_SC_E1_F3=43552, --> en hexa AA20<br />HK_LFR_SC_E2_F3=30992 --> en hexa 7910</p>
<p>EST CE NORMAL?????<br />Si oui mettre l explication.</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.7<br />VHDL 1.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EM1 sans Timegen<br />StarDundee</p> LFR-FSW - Bug #982 (Closed): Verification SC_potention V_F3https://hephaistos.lpp.polytechnique.fr/redmine/issues/9822017-03-16T10:31:33ZVeronique bouzid
<p>Voici le plots obtenus lors de la crétion de la ramp 2mn sur V<br />Le plot vert = HK<br />Le plot fushia = CWF_F3</p>
<p>le temps du 1er HK est 55.0289154052734375<br />le temps de la premiere cwf_f3 est 55.9727478027343750</p>
<p>Les données sont rangées dans le répertoire /home/validation/data/R3++/3.2.0.3/1.1.91/SC_potential_mean_HK_datasets/RampUp_2mn_on_V.<br />Les données sont également sur le ftp<br /><a class="external" href="ftp://ftp.lpp.polytechnique.fr/bouzid/keep/LFR/3.2.0.3/SC_potential_mean_HK_datasets/RampUp_2mn_on_V">ftp://ftp.lpp.polytechnique.fr/bouzid/keep/LFR/3.2.0.3/SC_potential_mean_HK_datasets/RampUp_2mn_on_V</a></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 #976 (Closed): HK_LFR_SC_V_F3 is erroneous https://hephaistos.lpp.polytechnique.fr/redmine/issues/9762017-03-13T14:04:08ZVeronique 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 #972 (Closed): Negative Parameters send into TC_LFR_LOAD_FILTER_PAR not rejected https://hephaistos.lpp.polytechnique.fr/redmine/issues/9722017-03-13T08:02:05ZVeronique bouzid
<p>L'envoi de valeurs négatives des paramètres suivants sur une TC_LFR_LOAD_FILTER_PAR sont accéptés par LFR software au lieu <br />d'etre rejeté par une TM_LFR_EXE_INCONSISTENT.</p>
<p>Cela concerne<br />- SY_LFR_SC_RW_DELTA_F (voir <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: Negative RW Frequency send into TC_LFR_UPDATE_INFO is taken in account (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/939">#939</a>) <br />- SY_LFR_RWi_Kj avec i = [1,4] et j = [1,4]</p>
<p>Les demandes de mise à jour de l'ICD ont été faites par Bruno.</p>
<p>Le script utilisé se nomme /opt/VALIDATION_R3plusplus/lfrverif/LFR_SVS/SVS-0008/tc_execution_failure_report.py.<br />Les fichiers de log (2017_03_10-14_25_30*) se trouvent dans le répertoire /home/validation/data/R3++/3.2.0.2/1.1.91/SVS-0008.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.2<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 #966 (Closed): Comment valider le SSS-CP-EQS-526https://hephaistos.lpp.polytechnique.fr/redmine/issues/9662017-03-10T13:24:12ZVeronique bouzid
<p>Thomas propose d injecter sur V_F3, E1_F3, E2_F3<br />- un signal sinusoidal à 0.1hz<br />- un signal carré à 0.1hz<br />- un signal sinusoidal à 10hz</p>
<p>Les tests ont été effectués sur pc-solar1 par Bruno en utilisant le LFR-GSE et le logiciel de generation des signaux<br />Pour cela on a utilisé une ANALOG DISCOVERY avec une pin connecté à V_f3 et dans un deuxieme temps 2 pins connectées sur E1_F3 et E2_F3.<br />Le logiciel de generation des signaux ne sait piloter que 2 signaux max.</p>
<p>Les résultats sont actuellement sur pc-solar3 dans le répertoire /home/validation/data/R3++/3.2.0.2/1.1.91/SC_potential_mean_HK_datasets.<br />Les fichiers générés sont<br />Sine_0.1Hz_on_E1E2_packet_log.data<br />Sine_0.1Hz_on_E1E2_packet_record.data<br />Sine_0.1Hz_on_V_packet_log.data<br />Sine_0.1Hz_on_V_packet_record.data<br />Sine_10Hz_on_E1E2_packet_log.data<br />Sine_10Hz_on_E1E2_packet_record.data<br />Sine_10Hz_on_V_packet_log.data<br />Sine_10Hz_on_V_packet_record.data<br />Square_0.1Hz_on_E1E2_packet_log.data<br />Square_0.1Hz_on_E1E2_packet_record.data<br />Square_0.1Hz_on_V_packet_log.data<br />Square_0.1Hz_on_V_packet_record.data</p>
<p>la decom R3++ de Bruno a été copiée dans le répertoire /home/validation/bin. Elle se nomme LFR_packet_decom-linux-x86_64<br />[validation@pc-solar3 bin]$ LFR_packet_decom-linux-x86_64</p>
*<strong><b></strong>*</b>**<strong>**</strong>*************************************<br />LFR instrument decommutation program version 0r107<br />ONLY COMPATIBLE WITH FSW 3.2.x DATADUMP (R3++)
<hr />
<p>Usage: LFR_packet_decom-linux-x86_64 [LFR L1 binary packets file]</p> LFR-FSW - Bug #957 (Closed): Erroneous PA_LFR_RW_MASK_F2_WORD2 on TM_LFR_PARAMETER_DUMP when R...https://hephaistos.lpp.polytechnique.fr/redmine/issues/9572017-03-03T15:05:34ZVeronique bouzid
<p>A nouveau, la fonction de calcul de masque ne donne pas la bonne valeur.<br />Le script utilisé /home/validation/SCRIPT/R3++/test_rw_one_freq_96.py envoie une TC_LFR_UPDATE_INFO avec CP_RPW_SC_RW1_F1 à 96.0 hz et nan dans toutes les autres valeurs.</p>
<p>Aucune TC_LOAD_FILTER_PAR n a ete envoyée.</p>
<p>13:46:33.997939, TC_LFR_UPDATE_INFO, <strong>CP_RPW_SC_RW1_F1=1119944703</strong>, CP_RPW_SC_RW1_F2=2147483647, CP_RPW_SC_RW1_F3=2147483647, CP_RPW_SC_RW1_F4=2147483647, CP_RPW_SC_RW2_F1=2147483647, CP_RPW_SC_RW2_F2=2147483647, CP_RPW_SC_RW2_F3=2147483647, CP_RPW_SC_RW2_F4=2147483647, CP_RPW_SC_RW3_F1=2139160575, CP_RPW_SC_RW3_F2=2147483647, CP_RPW_SC_RW3_F3=2147483647, CP_RPW_SC_RW3_F4=2147483647, CP_RPW_SC_RW4_F1=2147483647, CP_RPW_SC_RW4_F2=2147483647, CP_RPW_SC_RW4_F3=2147483647, CP_RPW_SC_RW4_F4=2147483647</p>
<p>La TM_LFR_HK positionne correctement le flag a enabled<br />13:46:34.693412, TM_LFR_HK, <strong>HK_LFR_SC_RW1_F1_FLAG: ENABLED = 1</strong>, HK_LFR_SC_RW1_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F4_FLAG: DISABLED = 0</p>
<p>La TM_LFR_PARAMETER_DUMP montre les masques calculés<br />13:46:37.001817, TM_LFR_PARAMETER_DUMP,<br /> PA_LFR_RW_MASK_F0_WORD1=0xffffffff, PA_LFR_RW_MASK_F0_WORD2=0xffffffff, PA_LFR_RW_MASK_F0_WORD3=0xffffffff, PA_LFR_RW_MASK_F0_WORD4=0xfffffffc, PA_LFR_RW_MASK_F1_WORD1=0xffffffff, PA_LFR_RW_MASK_F1_WORD2=0xffffffff, PA_LFR_RW_MASK_F1_WORD3=0xffffffff, PA_LFR_RW_MASK_F1_WORD4=0xffffff8f, PA_LFR_RW_MASK_F2_WORD1=0xfffffffe, <strong>PA_LFR_RW_MASK_F2_WORD2=0x7fffffff,</strong> PA_LFR_RW_MASK_F2_WORD3=0xffffffff, PA_LFR_RW_MASK_F2_WORD4=0xffffffff</p>
<p>Hors si on regarde le <a class="issue tracker-1 status-5 priority-5 priority-highest closed" title="Bug: Fonction setFBinMask: Calcul masque erroné (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/867">#867</a> les masques avaient été correctement calculés et montraient<br />PA_LFR_RW_MASK_F2_WORD2=0x3fffffff</p>
<p>Les fichiers de logs (2017_03_03-13_46_44*) se trouvent dans le répertoire /home/validation/data/R3++/3.2.0.2/1.1.91/TEST-UNITAIRES/test_rw_one_freq_96</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.2<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 #955 (Closed): HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 have amazing value...https://hephaistos.lpp.polytechnique.fr/redmine/issues/9552017-03-02T12:27:45ZVeronique bouzid
<p>En R3++, le requirement SSS-CP-EQS-526 doit calculer la moyenne des 16 dernieres valeurs du champ electrique echantilloné à F3.<br />Cela concerne les champs HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 stockés dans TM_LFR_HK.</p>
<p>Actuellement on observe sur ses sensors le bruits de fond et les valeurs varient peu.</p>
<p>Lors des changements de modes, on observe une grosse variation des valeurs suivantes soit sur la transition standby vers mode soit sur la transition mode vers standby.<br />Ici un exemple de la transition normal mode vers standby vers burst<br />11:20:39.823949, TM_LFR_HK, TIME=0x8000007d3a8a, HK_LFR_MODE: NORMAL = 1, HK_LFR_SC_V_F3=431, HK_LFR_SC_E1_F3=428, HK_LFR_SC_E2_F3=382<br />11:20:40.822544, TM_LFR_HK, TIME=0x8000007e3a78, HK_LFR_MODE: NORMAL = 1, HK_LFR_SC_V_F3=430, HK_LFR_SC_E1_F3=429, HK_LFR_SC_E2_F3=382<br />11:20:41.822561, TM_LFR_HK, TIME=0x8000007f3a77, <strong>HK_LFR_MODE: NORMAL = 1, HK_LFR_SC_V_F3=429, HK_LFR_SC_E1_F3=429, HK_LFR_SC_E2_F3=383</strong><br />11:20:42.822307, TM_LFR_HK, TIME=0x800000803a61, <strong>HK_LFR_MODE: STANDBY = 0, HK_LFR_SC_V_F3=4459, HK_LFR_SC_E1_F3=12623, HK_LFR_SC_E2_F3=9087</strong><br />11:20:43.822065, TM_LFR_HK, TIME=0x800000813a50, <strong>HK_LFR_MODE: STANDBY = 0, HK_LFR_SC_V_F3=421, HK_LFR_SC_E1_F3=450, HK_LFR_SC_E2_F3=8662</strong><br />11:20:44.822052, TM_LFR_HK, TIME=0x800000823a51, <strong>HK_LFR_MODE: BURST = 2, HK_LFR_SC_V_F3=16161, HK_LFR_SC_E1_F3=4477, HK_LFR_SC_E2_F3=12067</strong><br />11:20:45.822391, TM_LFR_HK, TIME=0x800000833a64,* HK_LFR_MODE: BURST = 2, HK_LFR_SC_V_F3=4565, HK_LFR_SC_E1_F3=412, HK_LFR_SC_E2_F3=4516*<br />11:20:46.823081, TM_LFR_HK, TIME=0x800000843a50, HK_LFR_MODE: BURST = 2, HK_LFR_SC_V_F3=431, HK_LFR_SC_E1_F3=429, HK_LFR_SC_E2_F3=383</p>
<p>Les transitions qui posent problemes sont<br />normal -> standby<br />burst -> standby<br />sbm1 -> standby<br />sbm2 -> standby<br />et<br />standby -> burst</p>
<p>le script utilisé est /home/validation/SCRIPT/R3++/just_all_mode.py.<br />Les fichiers de logs (2017_03_02-11_26_58-*) sont dans /home/validation/data/R3++/3.2.0.2/1.1.91/TEST-UNITAIRES/just_all_mode.</p>
<p>je joins le fichier resultat qui baliant les transitions de mode.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.2<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 #939 (Closed): Negative RW Frequency send into TC_LFR_UPDATE_INFO is taken in accounthttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9392017-02-15T14:10:36ZVeronique bouzid
<p>J ai classé en Bug ce test mais je ne suis pas sure !!!</p>
<p>Ce test envoie une frequence negative (-1.0) dans le champ CP_RPW_SC_RW1_F1 de la TC_LFR_UPDATE_INFO</p>
<p>14:45:59.204015, TC_LFR_UPDATE_INFO, 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=103, 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: UPDATE_INFO = 51, SOURCE_ID: MISSION_TIMELINE = 110, CP_PDU_SCM_ON_OFF: OFF = 0, CP_PDU_ANT3_ON_OFF: OFF = 0, CP_PDU_ANT2_ON_OFF: OFF = 0, CP_PDU_ANT1_ON_OFF: OFF = 0, CP_PDU_THR_ON_OFF: OFF = 0, CP_PDU_TDS_ON_OFF: OFF = 0, CP_PDU_LFR_ON_OFF: OFF = 0, CP_PDU_BIAS_ON_OFF: OFF = 0, CP_BIA_MODE_MUX_SET: SET_0 = 0, CP_BIA_MODE_HV_ENABLED: DISABLED = 0, CP_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, CP_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, CP_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, SPARE: 0x0, CP_BIA_BIAS1=614.578487(uA), CP_BIA_BIAS2=614.56492241(uA), CP_BIA_BIAS3=614.55125782(uA), CP_BIA_M1=26.223070035(V), CP_BIA_M2=-27.673988037(V), CP_BIA_M3=28.973391609(V), CP_BIA_PHV=-3.282354, CP_BIA_NHV=18.600006, CP_BIA_TEMP_ANT1_LF_PA=-1756.0849565, CP_BIA_TEMP_ANT2_LF_PA=-6703.2503965, CP_BIA_TEMP_ANT3_LF_PA=-6703.2503965, CP_BIA_TEMP_PCB=-6703.2503965, SPARE=0x0, CP_LFR_MODE_COPY: STANDBY = 0, CP_LFR_CALIB_ENABLED: DISABLED = 0, CP_TDS_MODE_COPY: STANDBY = 0, CP_THR_MODE_COPY: STANDBY = 0, CP_LFR_TEMP_SCM=256degC, CP_THR_TEMP_ANT1_HF_PA=7531, CP_THR_TEMP_ANT2_HF_PA=14725, CP_THR_TEMP_ANT3_HF_PA=25836, CP_RPW_SC_RW1_F1=3212836864,</p>
<p>La TC_LFR_UPDATE_INFO est prise en compte, le compteur HK_LFR_UPDATE_INFO_TC_CNT est incrementé dans TM_LFR_HK . La valeur négative n est donc pas interdite.<br />On va verifier les masques dans TM_LFR_PARAMETER_DUMP.<br />A_LFR_RW_MASK_F0_WORD1=0xffffffff, PA_LFR_RW_MASK_F0_WORD2=0xffffffff, PA_LFR_RW_MASK_F0_WORD3=0xffffffff, <strong>PA_LFR_RW_MASK_F0_WORD4=0xfffffffe</strong>, PA_LFR_RW_MASK_F1_WORD1=0xffffffff, PA_LFR_RW_MASK_F1_WORD2=0xffffffff, PA_LFR_RW_MASK_F1_WORD3=0xffffffff, <strong>PA_LFR_RW_MASK_F1_WORD4=0xfffffffe,</strong> PA_LFR_RW_MASK_F2_WORD1=0xffffffff, PA_LFR_RW_MASK_F2_WORD2=0xffffffff, PA_LFR_RW_MASK_F2_WORD3=0xffffffff, PA_LFR_RW_MASK_F2_WORD4=0xffffffff</p>
<p>On voit qu il a été mis à jour pour F0 et que ce masque positionne le bits de poids faible à 0 et également dans PA_LFR_RW_MASK_F1_WORD4.<br />EST CE UN BUG OU PAS?<br />Quel est notre comportement dans ce cas?</p>
<p>Le script est /home/validation/SCRIPT/R3++/test_rw_one_neg_freq.py et les fichiers (2017_02_15-14_46_09*) sont rangés dans le répertoire<br />/home/validation/data/R3++/3.2.0.1/1.1.91/TESTS-UNITAIRES/one_neg_freq.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.1<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 #934 (Closed): HK_LFR_SC_RW1_F1_FLAG not updated when RW1_F1 is sethttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9342017-02-14T09:02:34ZVeronique bouzid
<p>Voici le scénario utilisé<br />- Attente d'une TM_LFR_HK après la séquence de boot<br />--> tous les Flags sont disable<br />HK_LFR_SC_RW1_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F4_FLAG: DISABLED = 0</p>
<p>- Envoi d'une TC_LFR_UPDATE_INFO avec valeurs par défaut CP_RPW_SC_RWi_Fj= Nan<br />Pour cela on met la valeur 0x7FFFFFFF dans le champ associé à la frequence de la roue à inertie (2147483647)<br />CP_RPW_SC_RW1_F1=2147483647, CP_RPW_SC_RW1_F2=2147483647, CP_RPW_SC_RW1_F3=2147483647, CP_RPW_SC_RW1_F4=2147483647, CP_RPW_SC_RW2_F1=2147483647, CP_RPW_SC_RW2_F2=2147483647, CP_RPW_SC_RW2_F3=2147483647, CP_RPW_SC_RW2_F4=2147483647, CP_RPW_SC_RW3_F1=2147483647, CP_RPW_SC_RW3_F2=2147483647, CP_RPW_SC_RW3_F3=2147483647, CP_RPW_SC_RW3_F4=2147483647, CP_RPW_SC_RW4_F1=2147483647, CP_RPW_SC_RW4_F2=2147483647, CP_RPW_SC_RW4_F3=2147483647, CP_RPW_SC_RW4_F4=2147483647, CRC = 0xbcd6</p>
<p>Ok pour la TM_LFR_HK tous les flags sont à DISABLED et la TM_LFR_PARAMETER_DUMP.</p>
<p>- Envoi d'une TC_LFR_UPDATE_INFO avec CP_RPW_SC_RW1_F1=1119879168 ( c est à dire 96.0 hz)</p>
<p>la TM_LFR_HK est erronée, le flag n a pas été mis à jour<br /><strong>HK_LFR_SC_RW1_F1_FLAG: DISABLED = 0,</strong> HK_LFR_SC_RW1_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW1_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW2_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW3_F4_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F1_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F2_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F3_FLAG: DISABLED = 0, HK_LFR_SC_RW4_F4_FLAG: DISABLED = 0</p>
<p>La TM_LFR_PARAMETER_DUMP a mis à jour ses masques pour F1 et F2 <br />PA_LFR_RW_MASK_F0_WORD1=0xffffffff, PA_LFR_RW_MASK_F0_WORD2=0xffffffff, PA_LFR_RW_MASK_F0_WORD3=0xffffffff, <strong>PA_LFR_RW_MASK_F0_WORD4=0xfffffffc</strong>, <br />PA_LFR_RW_MASK_F1_WORD1=0xffffffff, PA_LFR_RW_MASK_F1_WORD2=0xffffffff, PA_LFR_RW_MASK_F1_WORD3=0xffffffff, <strong>PA_LFR_RW_MASK_F1_WORD4=0xffffff8f,</strong> <br /><strong>PA_LFR_RW_MASK_F2_WORD1=0xfffffffe, PA_LFR_RW_MASK_F2_WORD2=0x3fffffff,</strong> PA_LFR_RW_MASK_F2_WORD3=0xffffffff, PA_LFR_RW_MASK_F2_WORD4=0xffffffff</p>
<p><strong>--> VERIFIER SI MASQUES CORRECTEMENT CALCULES</strong></p>
<p>Le script utilisé est /home/validation/SCRIPT/R3++/send_one_update_info.py.<br />Les fichiers de log (2017_02_14-09_38_05*) se trouvent dans le répertoire /home/validation/data/R3++/3.2.0.1/1.1.91/TESTS-UNITAIRES/send_one_update_info.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.1<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 #912 (Closed): champ HK_LFR_SC_POTENTIEL_FLAG passe à OFFhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9122017-01-18T10:28:12ZVeronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3+/set_load_filter_par.py.</p>
<p>Normalement le champ HK_LFR_SC_POTENTIEL_FLAG est positionné à ON apres la sequence de boot. Je verifie donc que cette valeur nominale<br />ne change pas.<br />Dans ce test, j observe que le flag passe à OFF.<br />ici les traces de la sequence</p>
<p>09:00:32.563373, <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=16, (PACKET_SEQUENCE_CONTROL=0xc010), 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=0x80000012222c, 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: ERROR_WAIT = 1, SPARE=0x0, <strong>HK_LFR_SC_POTENTIEL_FLAG: ON = 1,</strong> HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,</p>
<p>09:00:32.889086, <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=21, 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: DISABLED = 0, SY_LFR_PAS_FILTER_MODULUS=4, SY_LFR_PAS_FILTER_TBAD=1065353216, SY_LFR_PAS_FILTER_OFFSET=0, SY_LFR_PAS_FILTER_SHIFT=1056964608, SY_LFR_PAS_FILTER_DELTA_F=1020054733, CRC = 0xf136</p>
<p>09:00:32.899891, <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=5, (PACKET_SEQUENCE_CONTROL=0xc005), 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=0x80000012782f, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000</p>
<p>09:00:33.563494, <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=17, (PACKET_SEQUENCE_CONTROL=0xc011), 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=0x80000013222c, 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: ERROR_WAIT = 1, SPARE=0x0, <strong>HK_LFR_SC_POTENTIEL_FLAG: OFF = 0</strong>, HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,</p>
<p>C'est le seul test pour l instant ou j ai observé ce phénomeme. Dans ce test on envoie 2 TC_LOAD_FILTER_PAR , la première n induit pas le changement du champ<br />HK_LFR_SC_POTENTIEL_FLAG mais la deuxieme OUI.</p>
<p>Les fichiers (2017_01_18-09_00_41*) sont rangés dans le repertoire /home/validation/data/R3+/3.1.0.6/3.1.91/TESTS-UNITAIRES/set_load_filter.</p>
<p>--> IL faut revoir le traitement de cette TC (voir <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: champ HK_LFR_PAS_FILTER_ENABLED non mis à jour apres envoi TC_LFR_LOAD_FILTER_PAR (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/911">#911</a>)</p>
<p>Contexte du test<br />----------------<br />FSW 3.1.0.6<br />VHDL 3.1.91<br />PFM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p>