Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-02-13T10:10:15ZRedmine
Redmine LFR-FSW - Task #4026 (Closed): Analyse GCOVhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40262023-02-13T10:10:15ZVeronique bouzid
<p><strong>Début de la couverture de Test en 3.3.0.16</strong></p>
<p>Une quinzaine de tests ont été joués. Avant de pousser plus loin, il faudrait traiter ses tests et évaluer la couverture atteinte.</p>
<p>Sur pc-solar3, dans le répertoire /opt/VALIDATION_R3.3/GCOV/3.3.0.16, voici les fichiers à traiter:</p>
<p>gcov_out_2023-02-13 09:10:52.635355.txt<br />gcov_out_2023-02-13 09:12:32.358845.txt<br />gcov_out_2023-02-13 09:15:53.533775.txt<br />gcov_out_2023-02-13 09:17:58.219268.txt<br />gcov_out_2023-02-13 09:23:23.893858.txt<br />gcov_out_2023-02-13 09:33:27.972367.txt<br />gcov_out_2023-02-13 09:37:47.458757.txt<br />gcov_out_2023-02-13 09:39:33.827127.txt<br />gcov_out_2023-02-13 09:41:52.977440.txt<br />gcov_out_2023-02-13 10:23:51.069120.txt (SVS-0002 à SVS-0010 + SVS-0059)</p> LFR-FSW - Task #3199 (Closed): Analyse couverture de tests 3.2.0.24https://hephaistos.lpp.polytechnique.fr/redmine/issues/31992018-11-13T09:46:29ZVeronique bouzid
<p>Tout se passe sur la machine rangiroa<br />rep = /home/bouzid/LFR/GCOV_3.2.0.24<br />ensuite les répertoires de test /home/bouzid/LFR/GCOV_3.2.0.24/SVS-xxxx.</p>
<p>Les répertoires SVS comprenant plusieurs scripts de test sont traités indépendamment, par exemple <br />SVS-0012 SVS-0012-step2 SVS-0012-burst SVS-0012-normal SVS-0012-sbm1 SVS-0012-sbm2</p>
<p>Les variables d environnement necessaires sont<br />export DROOT=${HOME}/LFR<br />export SGCOV=${DROOT}/LFR_FSW/libgcov/build_gcov_files.py<br />export DBUILD=${DROOT}/build-LFR_FSW-Desktop_Qt_5_11_2_GCC_64bit-Debug/<br />export DTEST=${DROOT}/GCOV_3.2.0.24</p>
<p>Chaque répertoire de test a son analyse gcov unitaire. On se met au debut de l arborescence de test<br />cd ${DTEST}<br />${SGCOV} -r ${DBUILD} -o /home/bouzid/LFR/GCOV_3.2.0.24/SVS-0053/ /home/bouzid/LFR/GCOV_3.2.0.24/SVS-0053/gcov_out_2018-11-13\ 08\:49\:49.309256.txt<br />puis on execute le script /home/bouzid/LFR/lance_rapport SVS-xxxx.</p>
<p>Les fichiers*.html seront crées dans le repertoire de test .</p>
<p>Ensuite pour obtenir l analyse complète, on se met dans le répertoire /home/bouzid/LFR/GCOV_3.2.0.24 et on lance la commande<br />../LFR_FSW/libgcov/gcovr.py -s ../LFR_FSW -o . -g /opt/rtems-4.10/bin/sparc-rtems-gcov .<br />ou bien le script /home/bouzid/LFR/lance_final</p>
<p>Liste des tests joués<br />SVS-0002 à SVS-0014 SVS-0018 à SVS-0022 SVS-0026 à SVS-0034 SVS-0038 SVS-0040 à SVS-0044 SVS-0053 à SVS-0057<br />SVS-0059 SVS-0064 à SVS-0065 SVS-0067 SVS-0069 SVS-0070 SVS-0071 SVS-0073 SVS-0074 SVS-0076 à SVS-0079 SVS-0081 à SVS-0083 SVS-0086 SVS-0089 à SVS-0091 SVS-0095 SVS-0096</p> LFR-FSW - Support #1090 (Feedback): Back to time managementhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10902017-04-27T07:43:37ZVeronique bouzid
<p>Premier cas de test<br />- LFR a booté, <br />Le soft remonte bien que le timecode est missing et la derniere erreur tracée est coherente avec cela<br />HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, , HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>- Envoi d'une TC_LFR_UPDATE_TIME avec 300ms apres une timecode invalid ( je mets 5)<br />TC_LFR_UPDATE_TIME, CCSDS_VERSION, CP_RPW_TIME=0x38f223010000</p>
<p>sur la TM_LFR_HK<br />HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>--> Le soft ne remonte aucune erreur et donc la derniere erreur tracée est toujours missing.</p>
<p>--> Peux-tu expliquer CELA</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> LFR-FSW - Feature #1068 (Closed): Champ CP_LFR_CALIB_ENABLED sur TC_LFR_UPDATE_INFOhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10682017-04-20T10:28:34ZVeronique bouzid
<p>Quand tu recois dans une TC_LFR_UPDATE_INFO, comment traites-tu le champ<br />CP_LFR_CALIB_ENABLED?<br />Vérifies-tu si ce champ est conforme avec le fait que la calibration a été demandée??</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> LFR-FSW - Bug #911 (Closed): champ HK_LFR_PAS_FILTER_ENABLED non mis à jour apres envoi TC_LFR_LO...https://hephaistos.lpp.polytechnique.fr/redmine/issues/9112017-01-18T10:14:24ZVeronique bouzid
<p>Le script utilisé est /home/validation/SCRIPT/R3+/set_load_filter_par.py.<br />Le scénario est le suivant<br />Pas d'envoi de TC_LFR_LOAD_FILTER_PAR<br />--> le champ HK_LFR_PAS_FILTER_ENABLED est bien initialisé à DISABLED (meme si ce n est pas la valeur par défaut déclarée dans ICD 4.1 et 4.3)</p>
<p>09:00:25.563361, <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=9, (PACKET_SEQUENCE_CONTROL=0xc009), 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=0x8000000b222c, 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, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, *HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0
*</p>
<p>Envoi de la TC_LFR_LOAD_FILTER_PAR avec SY_LFR_PAS_FILTER_ENABLED: ENABLED = 1</p>
<p>09:00:23.866993, <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, <strong>SY_LFR_PAS_FILTER_ENABLED: ENABLED = 1</strong>, 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 = 0x5fca</p>
<p>09:00:24.563394, <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=8, (PACKET_SEQUENCE_CONTROL=0xc008), 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=0x8000000a222c, 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, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, <strong>HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0,</strong><br />et<br />09:00:25.563361, <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=9, (PACKET_SEQUENCE_CONTROL=0xc009), 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=0x8000000b222c, 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, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, <strong>HK_LFR_PAS_FILTER_ENABLED: DISABLED = 0</strong></p>
<p>--> Le champ n est jamais mis à jour.</p>
<p>Les fichiers (2017_01_18-09_00_41*) sont rangés dans le répertoire /home/validation/data/R3+/3.1.0.6/3.1.91/TESTS-UNITAIRES/set_load_filter.</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> 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/8692016-12-29T14:37:33ZVeronique 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 #649 (Closed): CCSDS_TC_PKT_MAX_SIZE wrong: detection of a TC with wrong lengthhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6492016-03-08T07:27:00ZVeronique bouzid
<p>Le requirement suivant est passé de design a test.<br />Command packets (DPU Software to RPW analyzer flight software)<br />SSS-IF-DPS-EQ-180<br />Command packets (DPU SW to RPW analyzer SW)<br />The Analyzer Flight Software shall receive commands from the DPU Software as Telecommand<br />Source Packets according to [ES1] with a maximum length given below for each analyzer:<br />- LFR: SY_LFR_TC_MAX_LEN = <strong>228 bytes</strong> (i.e. 216 bytes of application data)</p>
<p>J'ai regardé dans ton code et toi tu testes si la longueur de la TC est < CCSDS_TC_PKT_MAX_SIZE qui vaut 255.</p>
<p>fsw_spacewire.c<br />--> lecture du buffer<br />estimatePacketslength = len -CCSDS_TC_TM_PACKET_OFFSET -3</p>
<p>-CCSDS_TC_TM_PACKET_OFFSET = 7<br />ensuite appel de la fonction tc_parser</p>
<p>cette fonction est dans le fichier tc_acceptance.c</p>
<p>*elle va verifier la longueur de la TC avec la valeur CCSDS_TC_PKT_MAX_SIZE = 255 et cela ce n est pas bon<br />WRONG_LEN_PKT
*</p>
<p>ensuite on verifie que la lg est compatible avec le subtype (tc_check_length)</p>
<p>ensuite il va envoyer uen send_tm_lfr_tc_exe_corrupted<br />il y a un champ currentTC_LEN_RCV = lg du buffer lu rangé dans un 16 bits.</p>
<p>Dans les logs voici ce que l on obtient:</p>
<p>15:56:39.56912, <b>* 32 <strong></b>, TM_LFR_TC_EXE_CORRUPTED, 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=25, 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=0x8000001f5a68, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xccf3, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=93, *PA_RPW_PKT_LEN_RCV_VALUE=231, PA_RPW_PKT_DATFIELDSIZE_CNT=231</strong>, PA_RPW_RCV_CRC=0x7b4, PA_RPW_COMPUTED_CRC=0x7b4</p>
<p>Les fichiers de test sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0003</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 - Task #636 (Closed): bad management of HK_LFR_AHB_CORRECTABLE https://hephaistos.lpp.polytechnique.fr/redmine/issues/6362016-02-26T11:29:57ZVeronique bouzid
<p>Paul a dit:<br />J'avais voulu faire un truc sioux mais ça n'a pas de sens, le compteur pourrait rester bloquer à 255. Je fais la correction.</p>
<p>1- le compteur ahb_correctable est mal géré
{<br /> housekeeping_packet.hk_lfr_ahb_correctable = ahb_correctable;<br /> }</p>
<pre><code>if (ahb_correctable > 255)
{<br /> housekeeping_packet.hk_lfr_ahb_correctable = 255;<br /> }<br /> else</code></pre>
<p>2- Ce compteur n'est pas comptabilisé dans HK_LFR_LE_CNT ou HK_LFR_ME_CNT.</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 - Feature #593 (In Progress): adapter tm_lfr_period.py au fonctionnement des modeshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5932016-01-26T08:29:15ZVeronique bouzid
<p>Le normal mode ne s'interrompant plus quand on commute vers sbm1 et sbm2, il faut modifier <br />la fonction tm_lfr_period.py qui testait le timing en fonction du mode actif.</p>
<p>Maintenant la prise en compte des TM_LFR_SCIENCE_NORMAL* doit etre global pour vérifier la continuté des timing.</p> LFR-FSW - Bug #560 (Closed): activer la vérification du cache du Leon3FThttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5602015-11-04T04:43:52ZVeronique 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 #508 (Closed): Field DESTINATION_ID into TM_LFR_KCOEFFICIENTS_DUMP non complianthttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5082015-09-24T14:08:47ZVeronique bouzid
<p>Le champ DESTINATION_ID = le champ SOURCE_ID de la TC_LFR envoyée<br />Ce n'est pas le cas, DESTINATION_ID = 0</p>
<p>14:50:23.011819, <strong>TC_LFR_DUMP_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=11420, (PACKET_SEQUENCE_CONTROL=0xec9c), PACKET_LENGTH=5, 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: DUMP_KCOEFFICIENTS = 95, <strong>SOURCE_ID: AOCS = 11</strong>, CRC = 0x19af</p>
<p>14:50:23.045264, <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=11, (PACKET_SEQUENCE_CONTROL=0xc00b), PACKET_LENGTH=3913, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, <strong>DESTINATION_ID: GROUND = 0</strong>, TIME=0x8000037bec96, 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: 30 , 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 , ...</p>
<p>le script joué est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0018/source_id_loop_step1.py<br />le fichier detail /home/validation/data/R3/3.0.0.8/1.1.89/SVS-0018/2015_09_23-14_51_13-Detail.txt</p>
<p>Contexte du test<br />----------------<br />----------------<br />FSW 3.0.0.8<br />VHDL 1.1.89<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> SocExplorer - Feature #497 (In Progress): Ajouter une fonction retournant l'etat du cachehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4972015-09-18T11:19:35ZVeronique bouzidLFR-FSW - Bug #456 (Closed): champs PA_BIA_ON_OFF AND al de TM_LFR_SCIENCE_NORMAL_BP*_F* ne sont...https://hephaistos.lpp.polytechnique.fr/redmine/issues/4562015-07-02T11:02:49ZVeronique bouzid
<p>Bug signalé depuis dans JIRA : <br /><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWMEB-508">https://jira-lesia.obspm.fr/browse/RPWMEB-508</a><br />-------------------------<br />Si on change la valeur du paramètre CP_PDU_BIAS_ON_OFF ( 0 vers 1) dans TC_LFR_UPDATE_INFO, on s'attend à voir ce parametre mis à jour dans les TM_LFR_SCIENCE<br />produite après la prise en compte de la TC_LFR_UPDATE_INFO. Le champ se nomme PA_BIA_ON_OFF dans TM_LFR_SCIENCE_NORMAL_BP* .</p>
<p>hors ce n'est pas le cas.</p>
<p>les logs<br />09:36:47.673516, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)<br />09:36:47.695604, TM_LFR_TC_EXE_SUCCESS, TIME=0x80000009fae2<br />09:36:48.696052, TC_LFR_UPDATE_INFO,*CP_PDU_BIAS_ON_OFF: ON = 1*<br />09:36:48.909631, TM_LFR_HK,HK_LFR_UPDATE_INFO_TC_CNT=1 --> prise en compte de TC_LFR_UPDATE_INFO</p>
<p>le premier BP ne voit rien, ce qui peut s'explique car l acquisition a pu commence avant la prise en compte deTC_LFR_UPDATe_INFO<br />09:36:51.738856, <strong>TM_LFR_SCIENCE_NORMAL_BP1_F0</strong>, TIME=0x80000009fadf, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong>, 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, PA_LFR_ACQUISITION_TIME=0x80000009fadf, SPARE=0x0, PA_LFR_N_BP1_BLK_NR_F0=11</p>
<p>malheureusement il n est jamais pris en compte aussi bien sur les BP1 que sur les BP2</p>
<p>09:36:55.738969, TM_LFR_SCIENCE_NORMAL_BP1_F0, <strong>TIME=0x8000000dfade</strong>, PA_LFR_SID_PKT: SC_N_BP1_F0 = 14, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>09:36:55.751354, TM_LFR_SCIENCE_NORMAL_BP1_F1, <strong>TIME=0x8000000dfaeb</strong>, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong>,</p>
<p>09:36:55.764467, TM_LFR_SCIENCE_NORMAL_BP1_F2, <strong>TIME=0x8000000dfbd0</strong>, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong>,</p>
<p>BP2<br />09:37:07.755408, TM_LFR_SCIENCE_NORMAL_BP2_F0, <strong>TIME=0x80000019fad9</strong>, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>09:37:07.75807, TM_LFR_SCIENCE_NORMAL_BP2_F1,*TIME=0x80000019fae6*, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>09:37:07.781859, TM_LFR_SCIENCE_NORMAL_BP2_F2, <strong>TIME=0x80000019fbcc</strong>, 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, <strong>PA_BIA_ON_OFF: OFF = 0</strong></p>
<p>Idem pour les parametres <br />CP_BIA_MODE_MUX_SET, CP_BIA_MODE_HV_ENABLED, CP_BIA_MODE_BIAS1_ENABLED, CP_BIA_MODE_BIAS2_ENABLED, CP_BIA_MODE_BIAS3_ENABLED<br />correspondant à <br />PA_BIA_MODE_MUX_SET, PA_BIA_MODE_HV_ENABLED, PA_BIA_MODE_BIAS1_ENABLED, PA_BIA_MODE_BIAS2_ENABLED, PA_BIA_MODE_BIAS3_ENABLED.</p>
<p>le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0077/update_info_cnt_normal.py</p>
<p>les fichiers de log (2015_07_02-09_42_14*) se trouvent dans /home/validation/data/R3/3.0.0.7/SVS-0077/normal.</p>
<p>Pour l'instant le script n'a testé que les BP en Normal mode. Reste à verifier les autres produits ....</p>
<p>Ce comportement n'est pas en conformité avec ce que Paul écrit dans sa doc <strong>SDD p35 req-lfr-srs-55_ed1</strong></p>
<p>Contexte du test<br />----------------<br />FSW 3.0.0.7<br />VHDL 1.1.83 (_c car chgt de contrainte sur timing)<br />EM sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481<br />StarDundee</p> LFR-FSW - Bug #354 (Closed): Bit HK_LFR_CALIB_ENABLED n'est pas géréhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3542015-03-06T10:33:38ZVeronique bouzid
<p>Lancement du script /opt/VALIDATION_R2/lfrverif/LFR_SVS/SVS-0003/loop_tm_lfr_tc_exe.py</p>
<p>Suite à l'envoi d'un TC_LFR_ENABLE_CALIBRATION et de TM_LFR_TC_EXE_SUCCESS, le paquet TM_LFR_HK montre que le bit HK_LFR_CALIB_ENABLED est à 0</p>
<p>14:29:40.226556, TC_LFR_ENABLE_CALIBRATION<br />14:29:40.238556, TM_LFR_TC_EXE_SUCCESS<br />14:29:40.317008, TM_LFR_HK,HK_LFR_CALIB_ENABLED: DISABLED = 0</p>
<p>De meme l'envoi de la commande TC_LFR_DISABLE_CALIBRATION ne permet pas de verifier que le bit est remis à zéro.</p>
<p>Contexte de test<br />FSW 2.0.2.2<br />VHDL 1.1.63<br />EM 1<br />SocExplorerEngine.getSocExplorer: Version = 0.4.5, Branch = default, Changeset = c4b98d42ee59<br />StarDundee spacewire<br />Mini-LFR n°5 en mode TIMEGEN</p>