INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012016-12-29T10:56:07ZRedmine
Redmine LFR-FSW - Bug #865 (Closed): Fonction setFBinMask erronéehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8652016-12-29T10:56:07ZVeronique bouzid
<p>Pour avancer sur l'analyse du bug <a class="issue tracker-1 status-5 priority-4 priority-high2 closed" title="Bug: Mauvais BIN filtrée suite à reception d'un UPDATE_INFO avec les fréquences RW : décalage de 1 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/864">#864</a> , je me suis permise de récuperer ta fonction setFBinMask et de la tester unitairement.</p>
<p>1- Cette boucle est erronée , la derniere valeur de k doit etre 2 et non 3<br /> for (k = 0; k <= 3; k++)
{<br /> bin = binToRemove[k];</p>
<p>--> la declaration du tableau est int binToRemove[ 3 ];<br />Si on a 3 bins à enlever tu vas superposer 4 masques.</p> LFR-FSW - Bug #657 (Closed): HK_LFR_xE_CNT doesn't manage the wrap of 8bits counter errorhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6572016-03-09T14:28:44ZVeronique bouzid
<p>En Analysant le passage à zero des compteurs d'erreurs suivants (HK_LFR_TIMECODE_MISSING et HK_LFR_TIME_NOT_SYNCHRO, j observe bien le passage de 255 vers 0<br />pour les compteurs d'erreur codés sur 8 bits mais l'effet non attendu est que les compteurs HK_LFR_xE_CNT qui eux sont codés sur 16 bits ne sont plus bons car<br />ils representent la somme des erreurs liées à une criticité et donc le fait qu'un compteur passe à 0 diminue la valeur du ce compteur HK_LFR_xE_CNT<br />Voici un extrait du fichier Detail.txt</p>
<p>15:54:46.122923, TM_LFR_HK, TIME=0x000000ff81da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=509,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: NOT_SYNCHRO = 25, HK_LFR_LAST_ER_TIME=0x8000013bd189, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=255</strong>, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254,</strong> HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>15:54:47.122944, TM_LFR_HK, TIME=0x0000010081da, HK_LFR_UPDATE_TIME_TC_CNT=255, <strong>HK_LFR_LE_CNT=254,</strong> HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x000001003270, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, <strong>HK_LFR_TIMECODE_MISSING=0,</strong> HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, <strong>HK_LFR_TIME_NOT_SYNCHRO=254</strong>, HK_LFR_TIME_TIMECODE_CTR=0</p>
<p>Ceci est donc valable pour n'importe quel compteur codé sur 8 bits et utilisé dans une somme.</p>
<p>Les fichiers (2016_02_25-16_00_04-) sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0078/not_synchro.<br />Probleme remonté en lancant verif_fields sur le fichier Detail.txt.<br />Le fichier sss_cp_eqs_050.txt met en evidence les observations et permet de valider les passages à zero des compteurs :</p>
<p>15:54:47.122944, TM_LFR_HK<br />HK_LFR_LE_CNT: res=254; exp>=509 HK_LFR_TIMECODE_MISSING: res=0; exp>=255</p>
<p>15:55:49.123074, TM_LFR_HK<br />HK_LFR_DPU_SPW_TICK_OUT_CNT: res=0; exp>=255 HK_LFR_DPU_SPW_LAST_TIMC: res=0; exp>=63</p>
<p>15:56:50.123381, TM_LFR_HK<br />HK_LFR_LE_CNT: res=1; exp>=256 HK_LFR_TIME_NOT_SYNCHRO: res=0; exp>=255</p>
<p>Le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0078/update_time_not synchro_cnt_wrap.py.</p>
<p>Contexte du test<br />---------------------<br />FSW 3.0.0.22<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #247 (Closed): Le champ TIME des TM (Cuc) reste à 0x800000000001https://hephaistos.lpp.polytechnique.fr/redmine/issues/2472014-10-15T11:32:19ZVeronique bouzid
<p>Suite à la modification de Paul (Target logical ID = 0x20) pour utiliser la STarDundee en mode routeur<br />le champ TIME des TM_LFR reste poistionnée à la valeur suivante 0x800000000001.</p>
<p>Les fichiers de log sont dans /home/validation et commencent par 2014_10_15-11_34_38.<br />Le script utilisé est /home/validation/SCRIPT/just_normal_mode.py.</p>
<p>Contexte de test<br />LFR_FSW_PATH = /opt/LFR-FSW/2.0.1.1/fsw<br />Bridge selection = StarDundee<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520</p>
<p>Carte EM.</p> LFR-FSW - Bug #182 (Closed): [JIRA] (RPWMEB-283) The content of the PA_LFR_ACQUISITION_TIME ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1822014-07-09T08:39:49ZVeronique bouzid
<p>Suite à la remontée par Philippe Plasson de l incident RPWMEB-283</p>
<p>J ai ecrit un test pour reproduire le bug.Ce script se nomme <strong>my_timeissue_normal.py</strong>. Il se trouve sous /home/validation.Il est en piece jointe.</p>
<p>J'ai envoyé un <strong>UPDATE_TIME</strong> avec comme temps de réference <strong>CP_RPW_TIME=0x1b45fd970000</strong><br />qui correspond au 1er juillet 2014 vers 23h10 . J ai mis le temps indiqué par Philippe sans vérifier que cela correspondait bien au 1er juillet 2014.<br />Je leur fais confiance.</p>
<p>Je vois bien la mise à l heure de LFR apres reception du time code<br />09:30:22.591245, TM_LFR_HK,TIME=0x8000000346da</p>
<p><strong>09:30:23.591236, TM_LFR_HK,TIME=0x1b45fd976093</strong></p>
<p>la premiere données scientifique qui arrive<br />09:30:23.991365, TM_LFR_SCIENCE_NORMAL_BP1_F0,*TIME=0x1b44fd97a7e4,PA_LFR_ACQUISITION_TIME=0x1b44fd97a7e4*</p>
<p><strong>et la BINGO, on voit 0x1b44 au lieu de 0x1b45</strong>*
*<br />idem pour toutes le TM</p>
<p>09:35:26.392595, TM_LFR_SCIENCE_NORMAL_SWF_F0, TIME=0x9b44febfa146,PA_LFR_ACQUISITION_TIME=0x9b44febfa146<br />09:35:28.59267, TM_LFR_SCIENCE_NORMAL_SWF_F1,TIME=0x9b44febf6c3e,PA_LFR_ACQUISITION_TIME=0x9b44febf6c3e</p>
<p>--------------------------------------------------------------------------------------<br />Contexte:</p>
<p>SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: 1.1.23<br />Soft: 2.0.0.0 <br />Brique Star-Dundee S/N 46120065.</p>
<p>script: /home/validation/my_timeissue.py</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue3_rev0</p> LFR-FSW - Bug #177 (Closed): EM : Envoi TC_LFR_LOAD_SBMx_PARAM est interdit en mode SBM1 et SBM2 https://hephaistos.lpp.polytechnique.fr/redmine/issues/1772014-06-20T07:43:37ZVeronique bouzid
<p>EN mode SBM1 et SBM2, on ne peut envoyer de TC_LFR_LOAD_SBM1_PARAM et TC_LFR_LOAD_SBM2_PARAM.<br />Gérald a décrit un tableau dans le requirement REQ-LFR-SRS-5207_Ed1 qui récapitule<br />ce que les TC autorisées en fct du mode de LFR et celui du DAS.</p>
<p>--> Il faut donc générer des TM_LFR_TC_EXE_NOT_EXECUTABLE au lieu des TM_LFR_TC_EXE_SUCCESS<br />Voici les traces<br />en SBM1<br />on ne doit pas accepter de changer les parametres du SBM2<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:30.394448, TM_LFR_HK, HK_LFR_MODE: SBM1 = 3<br />14:21:30.803258, TC_LFR_LOAD_SBM2_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=9018, (PACKET_SEQUENCE_CONTROL=0xe33a), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM2_PARAMETERS = 27, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S2_BP_P0 = 1, SY_LFR_S2_BP_P1 = 5, CRC = 0x76fa</p>
<p>14:21:30.894486, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=111, (PACKET_SEQUENCE_CONTROL=0xc06f), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001cbbc3, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe33a</p>
<p>on ne doit pas accepter de changer les parametres du SBM1<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:33.294332, TM_LFR_HK, HK_LFR_MODE: SBM2 = 4<br />14:21:33.697692, TC_LFR_LOAD_SBM1_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6413, (PACKET_SEQUENCE_CONTROL=0xd90d), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM1_PARAMETERS = 25, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S1_BP_P0 = 0.25(s), SY_LFR_S1_BP_P1 = 1(s), CRC = 0xa7e5</p>
<p>14:21:33.794294, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=121, (PACKET_SEQUENCE_CONTROL=0xc079), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001f9e39, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd90d</p>
<hr />
<p>Contexte:<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: EM_1.1.23<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.11 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0007<br />le fichierd'analyse est /home/validation/data/R2/SVS-0007/2014_06_19-14_21_35-Detail.txt</p> LFR-FSW - Bug #171 (Closed): TM_LFR_PARAMETER_DUMP et TM_LFR_HK est reçue avec CONTINUATION_PACKE...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1712014-06-16T12:56:47Zbruno katra
<p>D'après SSS-CP-EQS-415 : le segmentation grouping flag doit toujours être placé à 3 (standalone).<br />Ce n'est pas le cas pour TM_LFR_PARAMETER_DUMP et TM_LFR_HK</p>
<p>14:29:47.876692, TM_LFR_PARAMETER_DUMP, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: DUMP = 9, (PACKET_ID=0xcc9), <strong>SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0,</strong></p>
<p>14:29:47.325072, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), <strong>SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0,</strong></p>
<p>---------------------------------<br />Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065<br />Soft:1.0.0.9b (variante sur carte finale)</p>
<p>TEST CASE = SVS-0065<br />Req = SSS-CP-EQS-415</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue3_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #169 (Closed): En SBM1, l'arrivée d'un SWF fait planter le soft de vol.https://hephaistos.lpp.polytechnique.fr/redmine/issues/1692014-06-12T10:13:28Zbruno katra
<p>Le test SVS-0019 plante systématiquement le soft de vol au même moment (compteur HK = 543).<br />L'analyse du test de Gérald montre que cela se passe lorsqu'on est en SBM1.</p>
<p>Véro et Bruno sont en train de chercher plus précisément le contexte des paramètres qui provoque ce bug et sa reproductibilité.</p>
<p>------------------------------------------------<br />Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.8 (variante sur carte finale)</p>
<p>TEST CASE : SVS-0019</p> LFR-FSW - Bug #167 (Closed): TC_LFR_LOAD_NORMAL_PAR avec SY_LFR_N_BP_P0 = 0 fait planter le soft ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1672014-06-11T14:41:44Zbruno katra
<p>L'envoi de TC_LFR_LOAD_NORMAL_PAR avec SY_LFR_N_BP_P0 = 0 devrait renvoyé TM_LFR_TC_EXE_ERROR_INCONSISTENT (vf bug <a class="issue tracker-1 status-5 priority-5 priority-highest closed" title="Bug: TC_LFR_LOAD_NORMAL_PAR: SY_LFR_N_ASM_P, SY_LFR_N_BP_P0 et , SY_LFR_N_BP_P1 = 0 acceptés (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/85">#85</a>) mais au lieu de ça le soft freeze :<br />- plus d'ack<br />- plus de HK</p>
<p>La vidéo jointe à cette issue montre ce qui se passe.</p>
<p>-------------------------------------------<br />Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.8 (variante sur carte finale)</p>
<p>TEST CASE : script SY_LFR_N_BP_P0_failure.py dans SVS-0008</p> LFR-FSW - Bug #166 (Closed): PACKET LENGTH erroné pour TM_LFR_SCIENCE_BURST_BP1_F1 et TM_LFR_SCIE...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1662014-06-10T06:15:20ZVeronique bouzid
<p>EN analysant le fichier 2014_06_05-12_11_54-Detail.txt correspondant au test<br />SVS-0090/generate_science_all_modes.py<br />2 pbs sur le parametre PACKET LENGTH, la longueur du packet de telemetry ne correspond pas au champ contenu dans PACKET_LENGTH</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>.....</p>
<p>- 16:42:38.053034, TM_LFR_SCIENCE_BURST_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=3, (PACKET_SEQUENCE_CONTROL=0xc003), PACKET_LENGTH=217, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000025ac28, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>,</p>
<p>Ce probleme est présent sur d'autres tests (vu egalement sur 1.0.0.6)</p>
<p>Contexte<br />LPPMON Version = 0.2.2, Branch = default, Changeset = 835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.7 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N <strong>XX</strong>.</p> LFR-FSW - Bug #117 (Closed): Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/1172014-04-09T14:59:58ZGerald Saule
<p>Le champ SEQUENCE_CNT des TM correspond au nombre de TM pour chaque couple (PACKET_ID,DESTINATION_ID).<br />Il y a un pb d'homogénéïté lors de l'implémentation de cette affectation:<br />-Pour PACKET_ID=0xcfc et DESTINATION_ID: GROUND = 0 (TM_LFR_SCIENCE_SBM1_CWF_F1), la premier paquet est en SEQUENCE_CNT=0.<br />-Pour les autres couples, le premier paquet est en SEQUENCE_CNT=1.</p>
<p><strong>Les SEQUENCE_CNT doivent commencer à 0 dès la première TM (cf. mail Philippe Plasson 4/06/2014)</strong></p>
<p>D'autre part, il y a aussi un pb sur le pivot pour TM_LFR_SCIENCE_SBM1_CWF_F1 (PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0): après SEQUENCE_CNT=255, on repasse malheureusement à SEQUENCE_CNT=0.</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.9<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.5 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0019<br />Req = SSS-CP-FS-590</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #108 (Closed): Champs TIME et ACQUISITION_TIME différents dans les TM_LFR_SCIENCE_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/1082014-03-31T14:59:04Zbruno katra
<p>Dans les TM science, les 2 champs TIME ont des valeurs différentes alors que ceux-ci devraient avoir la même valeur ACQUISITION_TIME qui est le temps du premier échantillon du paquet (SSS-CP-EQS-410).</p>
<p>15:31:35.368491, TM_LFR_SCIENCE_BURST_CWF_F2, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=4051, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, <strong>TIME=0x800001fd7f1b</strong>, PA_LFR_SID_PKT: SC_B_CWF_F2 = 2, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, SPARE: 0x0, <strong>PA_LFR_ACQUISITION_TIME=0x800001f30000</strong>, PA_LFR_CWF_BLK_NR=336</p>
<p>Contexte:<br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.3 (variante sur carte finale) = r109</p>
<p>Brique Star-Dundee S/N illisible.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2<br />RPW-SYS---ICD-00067-LES_Issue2_Rev2_RPW_IDB_Parameter_Definition</p> LFR-FSW - Bug #104 (Closed): SY_LFR_FPGA_VERSION_N3 de TM_LFR_HK erronéhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1042014-03-28T13:17:19ZGerald Saule
<p>TM_LFR_HK, SY_LFR_FPGA_VERSION_N3=255 est une coquille.<br />On attend SY_LFR_FPGA_VERSION_N3=7.</p>
<p>Contexte:<br />LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.7<br />Soft: 1.0.0.4 (variante sur carte finale)<br />Brique Star-Dundee S/N <blank>.</p>
<p>TEST CASE = s.o.</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #85 (Closed): TC_LFR_LOAD_NORMAL_PAR: SY_LFR_N_ASM_P, SY_LFR_N_BP_P0 et , SY_LFR_N_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/852014-03-12T09:35:44ZGerald Saule
<p>Le LFR FSW accepte des périodes nulles. Ce n'est pas interdit par l'ICD; néanmoins, le comportement associé est indéfini.</p>
<blockquote>
<p>09:51:24.915628, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), <strong>SY_LFR_N_ASM_P = 0(s)</strong>, SY_LFR_N_BP_P0 = 4(s), SY_LFR_N_BP_P1 = 20(s)<br />09:51:24.918065, TM_LFR_TC_EXE_SUCCESS</p>
<p>09:51:25.116246, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 4(s), <strong>SY_LFR_N_BP_P0 = 0(s)</strong>, SY_LFR_N_BP_P1 = 20(s)<br />09:51:25.119052, TM_LFR_TC_EXE_SUCCESS</p>
<p>09:51:25.320007, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 4(s), SY_LFR_N_BP_P0 = 4(s), <strong>SY_LFR_N_BP_P1 = 0(s)</strong><br />09:51:25.321911, TM_LFR_TC_EXE_SUCCESS</p>
</blockquote>
<p><ins>Contexte:</ins><br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.2 (variante sur carte finale) = r104</p>
<p>Brique Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE associé(s) = SVS-0029.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #65 (Closed): TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/652014-02-24T14:13:06ZGerald Saule
<p>Cette issue reprend l'issue Bug <a class="issue tracker-4 status-5 priority-3 priority-high3 closed" title="Task: Delivery 3.1.0.5 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/905">#905</a> (TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1).</p>
<p>Pour TC_LFR_LOAD_NORMAL_PAR, les champs SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1 ne sont pas controlés.<br />La valeur 0 devrait être un moyen simple d'obtenir un rejet (il s'agit de périodes).<br />LFR retourne TM_LFR_TC_EXE_SUCCESS.</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.1 (variante sur carte finale)</p>
<p>TEST CASE = SVS_0008</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #57 (Closed): TC_LFR_LOAD_NORMAL_PAR renvoie TM_LFR_TC_EXE_NOT_IMPLEMENTED si SY_LF...https://hephaistos.lpp.polytechnique.fr/redmine/issues/572014-02-19T16:31:00ZGerald Saule
<p>Pour TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L affecté conformément à Bug #816 (SY_LFR_N_SWF_L: >=16, multiple de 16, <= 2048), mais différent de la valeur par défaut (2048).<br />L'acquittement retourne TM_LFR_TC_EXE_NOT_IMPLEMENTED (excepté en NORMAL).</p>
<blockquote>
<p>16:44:52.151797, TC_LFR_LOAD_NORMAL_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=830, (PACKET_SEQUENCE_CONTROL=0xc33e), PACKET_LENGTH=15, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_NORMAL_PARAMETERS_1 = 13, SOURCE_ID: TC_SEQUENCES = 111, SY_LFR_N_SWF_L = 16, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 3600(s), SY_LFR_N_BP_P0 = 4(s), SY_LFR_N_BP_P1 = 20(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3 = 1, SPARE=0x0, CRC = 0x4b87</p>
<p>16:44:52.15462, TM_LFR_TC_EXE_NOT_IMPLEMENTED, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=228, (PACKET_SEQUENCE_CONTROL=0xc0e4), PACKET_LENGTH=17, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: TC_SEQUENCES = 111, TIME=0x80016c046b62, PA_RPW_TC_FAILURE_CODE: FUNCT_NOT_IMPL = 42002, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc33e, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=13</p>
</blockquote>
<p>(Cette issue reprend Bug #835 de pc-instru)</p>
<p>Contexte:</p>
<p>LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.1 (variante sur carte finale)<br />Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001_step03</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>