Redmine: Issues
https://hephaistos.lpp.polytechnique.fr/redmine/
https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?1508097601
2023-01-24T11:00:35Z
Redmine
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/4015
2023-01-24T11:00:35Z
Veronique 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 #1085 (Closed): PA_RPW_BYTE_POSITION wrong into a TM_LFR_TC_EXE_INCONSISTENT on TC_...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/1085
2017-04-25T16:25:51Z
Veronique 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/1084
2017-04-25T16:04:21Z
Veronique 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/1005
2017-03-21T08:56:12Z
Veronique 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_F3
https://hephaistos.lpp.polytechnique.fr/redmine/issues/982
2017-03-16T10:31:33Z
Veronique 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 #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/955
2017-03-02T12:27:45Z
Veronique 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 #869 (Closed): champ SY_LFR_PAS_FILTER_DELTA_F de TM_LFR_PARAMETER_PAR non initiali...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/869
2016-12-29T14:37:33Z
Veronique bouzid
<p>En jouant le script /home/validation/SCRIPT/R3+/send_one_update_info.py, on envoie la séquence suivante<br />TC_LFR_UPDATE_INFO<br />TC_LFR_DUMP_PAR<br />TM_LFR_PARAMETER_DUMP</p>
<p>On voit bien qu'il n y a pas eu de TC_LOAD_FILTER_PAR d'envoyé.</p>
<p>--> on observe sur la TM_LFR_PARAMETER_DUMP que le parametre du champ SY_LFR_PAS_FILTER_DELTA_F n est pas initialisé à la valeur par défaut.<br />Le champ contient n'importe quoi.</p>
<p>SY_LFR_PAS_FILTER_ENABLED: DISABLED = 0, SY_LFR_PAS_FILTER_MODULUS=4, SY_LFR_PAS_FILTER_TBAD=1061109567, SY_LFR_PAS_FILTER_OFFSET=0, SY_LFR_PAS_FILTER_SHIFT=1061109567, <strong>SY_LFR_PAS_FILTER_DELTA_F=257701985340,</strong> 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=0xffffffff, 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=0xffffffff, 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, SPARE8_3=0x0</p>
<p>Les fichiers de logs (2016_12_28-09_46_13*) (sont dans le répertoire /home/validation/data/R3+/3.1.0.4/1.1.91/EM1/TESTS-UNITAIRES/send_one_update_info</p>
<p>Contexte du test<br />---------------------<br />FSW 3.1.0.4<br />VHDL 1.1.91<br />EM1 sans TIMEGEN</p>
LFR-FSW - Bug #629 (Closed): Lost TM_LFR_HK with timegen
https://hephaistos.lpp.polytechnique.fr/redmine/issues/629
2016-02-16T09:14:17Z
Veronique bouzid
<p>Je viens d'ecrire un petit test (/opt/VALIDATION_R3/my_test_mode.py qui ne dure que 6 secondes pour verifier si je peux reproduire la perte de HK. C'est le cas.</p>
<p>1- Lancement du script Timegen + set_time<br />2 on envoie une TC enter-mode en standby<br />3- on envoie une TC entre-mode en normal<br />4 on attend 5s (utilisation de la fct soc.wait(5)</p>
<p>les logs montrent la perte de JK<br />2016 2 16 09:59:50:426 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e55af94 3774<br />2016 2 16 09:59:50:429 TM_LFR_TC_EXE_SUCCESS time = 0x 1e55af94 3dbd<br />2016 2 16 09:59:50:570 TM_LFR_HK time = 0x 1e55af94 629a<br />2016 2 16 09:59:51:571 TM_LFR_HK time = 0x 1e55af95 629a<br />2016 2 16 09:59:52:571 TM_LFR_HK time = <strong>0x 1e55af97 629a</strong><br />2016 2 16 09:59:53:570 TM_LFR_HK time = 0x 1e55af98 6299<br />2016 2 16 09:59:54:570 TM_LFR_HK time = 0x 1e55af99 6299<br />2016 2 16 09:59:55:232 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1e55af95 1<br />2016 2 16 09:59:55:256 TM_LFR_SCIENCE_NORMAL_BP1_F1 time = 0x 1e55af95 1<br />2016 2 16 09:59:55:268 TM_LFR_SCIENCE_NORMAL_BP1_F2 time = 0x 1e55af95 e6</p>
<p>J'ai enregistré le format CSW qui me permet de verifier le sequence_cnt des HK<br />2016 2 16 09:59:50:426, 32, 2, 0, 0, 12, 193, 192, 0, 0, 19, 16, 1, 8, 254, 30, 85, 175, 148, 55, 116, 28, 204, 0, 0, 164, 16, 181, 41, 13, 81<br />2016 2 16 09:59:50:429, 32, 2, 0, 0, 12, 193, 192, 1, 0, 13, 16, 1, 7, 254, 30, 85, 175, 148, 61, 189, 28, 204, 0, 0</p>
<p>--> 3 25 indique TM_LFR_HK et le SEQUENCE_CNT est en gras et correct<br />2016 2 16 09:59:50:570, 32, 2, 0, 0, 12, 196, <strong>192, 7,</strong> 0, 129, 16, <strong>3, 25</strong>, 0, 30, 85, 175, 148, 98, 154, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89, ....<br />2016 2 16 09:59:51:571, 32, 2, 0, 0, 12, 196, <strong>192, 8,</strong> 0, 129, 16, 3, 25, 0, 30, 85, 175, 149, 98, 154, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89, ....<br />2016 2 16 09:59:52:571, 32, 2, 0, 0, 12, 196, <strong>192, 9,</strong> 0, 129, 16, 3, 25, 0, 30, 85, 175, 151, 98, 154, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89, <br />2016 2 16 09:59:53:570, 32, 2, 0, 0, 12, 196, <strong>192, 10</strong>, 0, 129, 16, 3, 25, 0, 30, 85, 175, 152, 98, 153, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89,</p>
<p>--> Il n'y a pas de perte de HK si on se fit au SEQUENCE_CNT mais plutot une erreur de datation.</p>
<p>Les fichiers (2016_02_16_09_59_50*) sont dans /home/validation.</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>
LFR-FSW - Bug #560 (Closed): activer la vérification du cache du Leon3FT
https://hephaistos.lpp.polytechnique.fr/redmine/issues/560
2015-11-04T04:43:52Z
Veronique bouzid
<p>Lors de la vérification de l'activation du cache Alexis a posé la question suivante à Paul:</p>
<p>"J'ai trouvée ça dans la doc(grip p822 70.11.4 Cache control register) pour le cache: 20:19 FT scheme (FT) - “00” = no FT, “01” = 4-bit checking implemented. Tu l'actives?"</p>
<p>La réponse de Paul<br /> Ma réponse était non. Il faudra que je le fasse pour une utilisation dans le cadre FT.</p>
<p>Il faut donc implemeter cette fonctionalité et mettre à jour la SRS en conséquence.<br />Il reste à déterminer comment valider la mise en place de cette fonctionalité (Alexis et Véronique!!)</p>
LFR-FSW - Bug #535 (Closed): Field HK_LFR_LAST_EXE_TC_SUBTYPE incorrect if aTC_LFR_LOAD_FBINS_MAS...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/535
2015-10-05T10:23:29Z
Veronique bouzid
<p>La commande TC_LFR_LOAD_FBINS_MASK n'est pas bien décrite dans le packet TM_LFR_HK.</p>
<p>En effet, le champ SERVICE_SUBTYPE: LOAD_FBINS_MASK = 93 devient dans la TM_LFR_HK, HK_LFR_LAST_EXE_TC_SUBTYPE=91.. Par contre les autres champs<br />- HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_TIME=0x8000008f2ebb sont corrects</p>
<p>12:00:09.661454, <strong>TC_LFR_LOAD_FBINS_MASK</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=10208, (PACKET_SEQUENCE_CONTROL=0xe7e0), PACKET_LENGTH=53, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, <strong>SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_FBINS_MASK = 93</strong>, SOURCE_ID: RECOVERY_ACTION_CMD = 112, FBINS_F0_WORD1 = 0xffffffff,FBINS_F0_WORD2 = 0xffffffff,FBINS_F0_WORD3 = 0xffffffff,FBINS_F0_WORD4 = 0xffffffff,FBINS_F1_WORD1 = 0xffffffff,FBINS_F1_WORD2 = 0xffffffff,FBINS_F1_WORD3 = 0xffffffff,FBINS_F1_WORD4 = 0xffffffff,FBINS_F2_WORD1 = 0xffffffff,FBINS_F2_WORD2 = 0xffffffff,FBINS_F2_WORD3 = 0xffffffff,FBINS_F2_WORD4 = 0xffffffff,CRC = 0x1147</p>
<p>12:00:09.670408, <strong>TM_LFR_TC_EXE_SUCCESS</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=690, (PACKET_SEQUENCE_CONTROL=0xc2b2), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, <strong>TIME=0x8000008f2ebb</strong>, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe7e0</p>
<p>12:00:09.680432, <strong>TM_LFR_HK</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=141, (PACKET_SEQUENCE_CONTROL=0xc08d), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000008f31b4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: NORMAL = 1, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: POWER_ON = 1, SY_LFR_SW_VERSION_N1=3, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=9, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=89, HK_LFR_CPU_LOAD=11.7647058824, HK_LFR_CPU_LOAD_MAX=16.862745098, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_Q_SD_FIFO_SIZE_MAX=4, HK_LFR_Q_SD_FIFO_SIZE=50, HK_LFR_Q_RV_FIFO_SIZE_MAX=1, HK_LFR_Q_RV_FIFO_SIZE=10, HK_LFR_Q_P0_FIFO_SIZE_MAX=1, HK_LFR_Q_P0_FIFO_SIZE=10, HK_LFR_Q_P1_FIFO_SIZE_MAX=1, HK_LFR_Q_P1_FIFO_SIZE=10, HK_LFR_Q_P2_FIFO_SIZE_MAX=1, HK_LFR_Q_P2_FIFO_SIZE=5, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=609, HK_LFR_REJ_TC_CNT=55, HK_LFR_LAST_EXE_TC_ID=0x1ccc, <strong>HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=91,</strong> <strong>HK_LFR_LAST_EXE_TC_TIME=0x8000008f2ebb</strong>, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=41, HK_LFR_LAST_REJ_TC_TIME=0x800000598e1b</p>
<p>Cette fois j'ai bien verifié le fichier tm.csv et les valeurs sont identiques à celles communiquées ci-dessous. Donc pas de probleme de traduction.</p>
<p>le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0019/tm_sequence_counter_loop.py et les fichiers de test <br />sont rangés dans /home/validation/data/R3/3.0.0.9/1.1.89/SVS-0019.</p>
<p><strong>--> Vérifiez le comportement en cas d'erreur en attendant à chaque fois la HK pour vérifier les champs.</strong></p>
<p>J'ai retrouvé un jeu de test datant du 13/05/2015 (/home/validation/data/R3/JUST-STBY-FBINS) , le bug etait déja présent et la version du soft 3.0.0.0.<br />Donc l'erreur ne vient pas des modifications récentes.</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.9<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p>
LFR-FSW - Bug #480 (Closed): R3 *** HK_LFR_MAG_FIELDS_FLAG never updated
https://hephaistos.lpp.polytechnique.fr/redmine/issues/480
2015-08-07T08:14:56Z
Veronique bouzid
<p><strong>METTRE A JOUR LA SRS AVEC LA REPONSE DE PHILIPPE</strong></p>
<hr />
<p>le champ HK_LFR_MAG_FIELDS_FLAG est codé sur sur 1 bit. Au démarrage de LFR HK_LFR_MAG_FIELDS_FLAG = 0</p>
<p>Paul me précise qu il est mis à jour quand les données magnétiques sont présentes (SY_LFR_N_CWF_LONG_F3=1).</p>
<p>J'utilise le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0029/normal_mode_parameter_set.py</p>
<p>Ici la trace<br />17:57:17.849348, <strong>TM_LFR_PARAMETER_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: DUMP = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6, (PACKET_SEQUENCE_CONTROL=0xc006), PACKET_LENGTH=77, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: PARAMETER_DUMP = 32, DESTINATION_ID: GROUND = 0, TIME=0x80001533aa3b, PA_LFR_HK_SID: LFR_DUMP_SID = 10, SPARE=0x0, SY_LFR_BW=1, SY_LFR_SP0=0, SY_LFR_SP1=0, SY_LFR_R0=0, SY_LFR_R1=0, SY_LFR_R2=0, SY_LFR_N_SWF_L=2048, /!\SY_LFR_N_SWF_P=65535(s), SY_LFR_N_ASM_P=65535(s), SY_LFR_N_BP_P0=255(s), SY_LFR_N_BP_P1=255(s), SPARE=0x0, <strong>SY_LFR_N_CWF_LONG_F3=1</strong>, SPARE=0x0, SY_LFR_B_BP_P0=1(s), SY_LFR_B_BP_P1=5(s), SY_LFR_S1_BP_P0=0.25(s), SY_LFR_S1_BP_P1=1(s), SY_LFR_S2_BP_P0=1(s), SY_LFR_S2_BP_P1=5(s), SY_LFR_FBINS_F0_WORD1=0xffffffff, SY_LFR_FBINS_F0_WORD2=0xffffffff, SY_LFR_FBINS_F0_WORD3=0xffffffff, SY_LFR_FBINS_F0_WORD4=0xffffffff, SY_LFR_FBINS_F1_WORD1=0xffffffff, SY_LFR_FBINS_F1_WORD2=0xffffffff, SY_LFR_FBINS_F1_WORD3=0xffffffff, SY_LFR_FBINS_F1_WORD4=0xffffffff, SY_LFR_FBINS_F2_WORD1=0xffffffff, SY_LFR_FBINS_F2_WORD2=0xffffffff, SY_LFR_FBINS_F2_WORD3=0xffffffff, SY_LFR_FBINS_F2_WORD4=0xffffffff, SPARE8_2=0x0</p>
<p>17:57:18.038364, <strong>TC_LFR_ENTER_MODE (CP_LFR_MODE=1)</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=13, 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: ENTER_MODE = 41, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000000000, CRC = 0xca9b</p>
<p>17:57:18.061269, <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=24, (PACKET_SEQUENCE_CONTROL=0xc018), 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=0x80001533e0f4, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000</p>
<p>17:57:18.385053, 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), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=5426, (PACKET_SEQUENCE_CONTROL=0xd532), 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=0x8000153433da, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: NORMAL = 1, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, <strong>HK_LFR_MAG_FIELDS_FLAG: OFF = 0</strong>,</p>
<p>Ce champ n'est jamais mis à jour car pas pris en compte.</p>
<p>le fichier de trace est dans /home/validation/data/R3/3.0.0.8/1.1.88/SVS-0029/2015_07_28-18_32_00-Detail.txt</p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.8<br />VHDL 1.1.88<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p>
LFR-FSW - Bug #362 (Closed): CWF_F3 : Champ PA_LFR_ACQUISITION_TIME=0x000000000000
https://hephaistos.lpp.polytechnique.fr/redmine/issues/362
2015-03-10T11:44:13Z
Veronique bouzid
<p>Le systeme est à l heure (setTime.py),<br />on joue le script /home/validation/SCRIPT/just_normal_mode.py quijoue le Normal Mode durant 2h 1mn</p>
<p>La premiere salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 montre un mauvais champ PA_LFR_ACQUISITION_TIME qui vaut 0x000000000000.</p>
<p>11:42:31.207358, TC_LFR_ENTER_MODE, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000000000<br />11:42:31.239434, TM_LFR_TC_EXE_SUCCESS, TIME=0x1c7f20255cad<br />11:45:19.192084, TM_LFR_SCIENCE_NORMAL_CWF_F3, <strong>PA_LFR_ACQUISITION_TIME=0x000000000000</strong><br />11:45:19.232713, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x0000002a0000<br />11:45:19.264199, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x000000540000<br />11:45:19.278873, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x0000007e0000<br />Le delta entre chaque TM_LFR_SCIENCE_NORMAL_CWF_F3 est bon (2a = 42s).</p>
<p>Par contre la deuxieme salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 est correcte<br />11:48:06.886975, TM_LFR_HK, TIME=0x1c7f21750170, HK_LFR_MODE: NORMAL = 1<br />11:48:07.190201, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f20cd4c2e<br />11:48:07.211115, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f20f74c2e<br />11:48:07.242629, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f21214c2e<br />11:48:07.255938, TM_LFR_SCIENCE_NORMAL_CWF_F3, PA_LFR_ACQUISITION_TIME=0x1c7f214b4c2e</p>
<p>Les fichiers résultats sont dans /home/validation/data/R2+/JUST-NORMAL</p>
<p>Contexte du test<br />-----------------<br />FSW 2.0.2.2<br />VHDL 1.1.63<br />EM 1<br />SocExplorer 0.4.7 (attention s affiche 0.4.5 dans le fichier Nb.txt)<br />StarDundee spacewire<br />Mini-LFR n°5 en mode TIMEGEN</p>
LFR-FSW - Bug #184 (Closed): [JIRA] (RPWMEB-282) Generation period of TM_LFR_SCIENCE_NORMAL_CWF_F...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/184
2014-07-18T10:18:06Z
Veronique bouzid
<p>It is expected to have one TM_LFR_SCIENCE_NORMAL_CWF_F3 packet produced every 42 seconds.</p>
<p>LFR produces 4 TM_LFR_SCIENCE_NORMAL_CWF_F3 packets every 168 seconds (4 x 42 seconds), with an interval of 10 seconds between each packet.</p>
<p>Could LFR team clarify this point?</p>
<p>For the LFR TM analysis, it should be better to have one TM_LFR_SCIENCE_NORMAL_CWF_F3 packet every 42 seconds.</p>
<p>La reponse de Paul</p>
<p>This is linked to the way the hardware is performing the data acquisition in LFR. We have buffers of 2688 points inside the VHDL (this is a compromise between several constraints: the size of each individual packet requested by the DAS team, the fact that 4 different frequency snapshots are built at the same time, the fact that snapshots and continuous waveforms are built simultaneously in several modes...).<br />Once the buffer is full, an interruption request is raised and the flight software processes the buffer. The time before receiving the first packet can not be changed, it is 2688/16 for the CWF_F3 products. The time BETWEEN the packets can be changed. At the current time, it is 10s but we can increase it if is more practical for the DAS.</p>
<p>La reponse de Philippe est <strong>OK, this behavior shall be documented in the LFR S/W User Manual.</strong></p>
LFR-FSW - Bug #182 (Closed): [JIRA] (RPWMEB-283) The content of the PA_LFR_ACQUISITION_TIME ...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/182
2014-07-09T08:39:49Z
Veronique bouzid
<p>Suite à la remontée par Philippe Plasson de l incident RPWMEB-283</p>
<p>J ai ecrit un test pour reproduire le bug.Ce script se nomme <strong>my_timeissue_normal.py</strong>. Il se trouve sous /home/validation.Il est en piece jointe.</p>
<p>J'ai envoyé un <strong>UPDATE_TIME</strong> avec comme temps de réference <strong>CP_RPW_TIME=0x1b45fd970000</strong><br />qui correspond au 1er juillet 2014 vers 23h10 . J ai mis le temps indiqué par Philippe sans vérifier que cela correspondait bien au 1er juillet 2014.<br />Je leur fais confiance.</p>
<p>Je vois bien la mise à l heure de LFR apres reception du time code<br />09:30:22.591245, TM_LFR_HK,TIME=0x8000000346da</p>
<p><strong>09:30:23.591236, TM_LFR_HK,TIME=0x1b45fd976093</strong></p>
<p>la premiere données scientifique qui arrive<br />09:30:23.991365, TM_LFR_SCIENCE_NORMAL_BP1_F0,*TIME=0x1b44fd97a7e4,PA_LFR_ACQUISITION_TIME=0x1b44fd97a7e4*</p>
<p><strong>et la BINGO, on voit 0x1b44 au lieu de 0x1b45</strong>*
*<br />idem pour toutes le TM</p>
<p>09:35:26.392595, TM_LFR_SCIENCE_NORMAL_SWF_F0, TIME=0x9b44febfa146,PA_LFR_ACQUISITION_TIME=0x9b44febfa146<br />09:35:28.59267, TM_LFR_SCIENCE_NORMAL_SWF_F1,TIME=0x9b44febf6c3e,PA_LFR_ACQUISITION_TIME=0x9b44febf6c3e</p>
<p>--------------------------------------------------------------------------------------<br />Contexte:</p>
<p>SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: 1.1.23<br />Soft: 2.0.0.0 <br />Brique Star-Dundee S/N 46120065.</p>
<p>script: /home/validation/my_timeissue.py</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue3_rev0</p>
LFR-FSW - Bug #176 (Closed): EM : 2 reponses suite à Envoi TC_LFR_LOAD_*_PARAM ds le mode coura...
https://hephaistos.lpp.polytechnique.fr/redmine/issues/176
2014-06-20T07:33:11Z
Veronique bouzid
<p>On est en BURST MODE<br /><strong>14:21:27.294332, TM_LFR_HK, HK_LFR_MODE: BURST = 2,</strong></p>
<p>On envoie une TC_LFR_LOAD_BURST_PAR (parametres = parametres par défaut)<br />14:21:27.315331, <strong>TC_LFR_LOAD_BURST_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, (<strong>PACKET_ID=0x1ccc</strong>), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=11378, (<strong>PACKET_SEQUENCE_CONTROL=0xec72</strong>), 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_BURST_PARAMETERS_1 = 19, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_B_BP_P0 = 1(s), SY_LFR_B_BP_P1 = 5(s), CRC = 0xd3ae</p>
<p>--> 2 réponses à cette TC:<br /> - la première est correcte, on ne peut executer un TC_LFR_LOAD_*_PARAM d'un mode courant<br /> - la seconde qui n'a pas lieu d'arriver</p>
<p>14:21:27.394354, <strong>TM_LFR_TC_EXE_NOT_EXECUTABLE</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=96, (PACKET_SEQUENCE_CONTROL=0xc060), 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, <strong>TIME=0x80000019384c</strong>, PA_RPW_TC_FAILURE_CODE: TC_NOT_EXE = 42000, <strong>PA_RPW_TELECOMMAND_PKT_ID=0x1ccc</strong>, <strong>PA_RPW_PKT_SEQ_CONTROL=0xec72</strong>, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=19, HK_LFR_MODE: BURST = 2, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0</p>
<p>14:21:27.394686, <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=97, (PACKET_SEQUENCE_CONTROL=0xc061), 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, <strong>TIME=0x80000019385f</strong>, <strong>PA_RPW_TELECOMMAND_PKT_ID=0x1ccc</strong>, <strong>PA_RPW_PKT_SEQ_CONTROL=0xec72</strong></p>
<p>Ce cas est vu également en mode SBM1</p>
<p>14:21:30.597768, <strong>TC_LFR_LOAD_SBM1_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, (<strong>PACKET_ID=0x1ccc)</strong>, SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=10640, (<strong>PACKET_SEQUENCE_CONTROL=0xe990</strong>), 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 = 0xb801</p>
<p>14:21:30.694349, <strong>TM_LFR_TC_EXE_NOT_EXECUTABLE</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=109, (PACKET_SEQUENCE_CONTROL=0xc06d), 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, <strong>TIME=0x8000001c85dc</strong>, PA_RPW_TC_FAILURE_CODE: TC_NOT_EXE = 42000, <strong>PA_RPW_TELECOMMAND_PKT_ID=0x1ccc</strong>, <strong>PA_RPW_PKT_SEQ_CONTROL=0xe990,</strong> PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=25, HK_LFR_MODE: SBM1 = 3, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0</p>
<p>14:21:30.694638, <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=110, (PACKET_SEQUENCE_CONTROL=0xc06e), 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, <strong>TIME=0x8000001c85ed</strong>, <strong>PA_RPW_TELECOMMAND_PKT_ID=0x1ccc</strong>, <strong>PA_RPW_PKT_SEQ_CONTROL=0xe990</strong></p>
<p>et en SBM2<br />14:21:33.898319, <strong>TC_LFR_LOAD_SBM2_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, (<strong>PACKET_ID=0x1ccc</strong>), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=10523, (<strong>PACKET_SEQUENCE_CONTROL=0xe91b</strong>), 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 = 0xaee4</p>
<p>14:21:33.99446, <strong>TM_LFR_TC_EXE_NOT_EXECUTABLE</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=122, (PACKET_SEQUENCE_CONTROL=0xc07a), 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, <strong>TIME=0x8000001fd3ac</strong>, PA_RPW_TC_FAILURE_CODE: TC_NOT_EXE = 42000, <strong>PA_RPW_TELECOMMAND_PKT_ID=0x1ccc</strong>, <strong>PA_RPW_PKT_SEQ_CONTROL=0xe91b</strong>, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=27, HK_LFR_MODE: SBM2 = 4, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0</p>
<p>14:21:33.994742, <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=123, (PACKET_SEQUENCE_CONTROL=0xc07b), 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, <strong>TIME=0x8000001fd3be</strong>, <strong>PA_RPW_TELECOMMAND_PKT_ID=0x1ccc</strong>, <strong>PA_RPW_PKT_SEQ_CONTROL=0xe91b</strong></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</p>