Project

General

Profile

Bug #113

Affectation des champs de TM_LFR_HK en fin de boot du LFR

Added by Gerald Saule over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/04/2014
Due date:
% Done:

0%

Estimated time:
Spent time:
revision:
r110

Description

Les HK de début d'execution sont en

11:26:59.425762, 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=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=117, 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=0x800001a1d101, 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: RUN = 5, SPARE=0x0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: UNKNOWN_CAUSE = 0, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=4, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=2, SY_LFR_FPGA_VERSION_N3=255, HK_LFR_CPU_LOAD=0.0, HK_LFR_CPU_LOAD_MAX=0.0, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=0, HK_LFR_REJ_TC_CNT=0, HK_LFR_LAST_EXE_TC_ID=0x0, HK_LFR_LAST_EXE_TC_TYPE=0, HK_LFR_LAST_EXE_TC_SUBTYPE=0, HK_LFR_LAST_EXE_TC_TIME=0x000000000000, HK_LFR_LAST_REJ_TC_ID=0x0, HK_LFR_LAST_REJ_TC_TYPE=0, HK_LFR_LAST_REJ_TC_SUBTYPE=0, HK_LFR_LAST_REJ_TC_TIME=0x000000000000, HK_LFR_LE_CNT=0, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: NO_ERROR = 0, HK_LFR_LAST_ER_CODE: NO_ERROR = 0, HK_LFR_LAST_ER_TIME=0x000000000000, HK_LFR_VHDL_AA=0, HK_LFR_VHDL_SM=0, HK_LFR_VHDL_FFT=0, HK_LFR_VHDL_SR=0, HK_LFR_VHDL_CIC=0, HK_LFR_VHDL_HK=0, HK_LFR_VHDL_IIR=0, HK_LFR_VHDL_CAL=0, HK_LFR_DPU_SPW_PKT_RCV_CNT=0, HK_LFR_DPU_SPW_PKT_SENT_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LAST_FAIL_ADDR=0x0, HK_LFR_TEMP_SCM=0degC, HK_LFR_TEMP_PCB=0degC, HK_LFR_TEMP_FPGA=0degC, HK_LFR_SC_V_F3=0, HK_LFR_SC_E1_F3=0, HK_LFR_SC_E2_F3=0, 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, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0, HK_LFR_BUFFER_DPU_TC_FIFO=0, HK_LFR_BUFFER_DPU_TM_FIFO=0, HK_LFR_AHB_CORRECTABLE=0, HK_LFR_AHB_UNCORRECTABLE=0, SPARE=0x0

11:26:59.427046, 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=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=117, 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=0x940040134f90, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, /!\HK_LFR_MODE: 15, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, /!\HK_LFR_DPU_SPW_LINK_STATE: 7, /!\SPARE=0x7, SY_LFR_WATCHDOG_ENABLED: ENABLED = 1, HK_LFR_CALIB_ENABLED: ENABLED = 1, /!\HK_LFR_RESET_CAUSE: 7, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=4, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=2, SY_LFR_FPGA_VERSION_N3=255, HK_LFR_CPU_LOAD=100.0, HK_LFR_CPU_LOAD_MAX=100.0, HK_LFR_CPU_LOAD_AVE=100.0, HK_LFR_UPDATE_INFO_TC_CNT=65535, HK_LFR_UPDATE_TIME_TC_CNT=65535, HK_LFR_EXE_TC_CNT=65535, HK_LFR_REJ_TC_CNT=65535, HK_LFR_LAST_EXE_TC_ID=0xffff, HK_LFR_LAST_EXE_TC_TYPE=65535, HK_LFR_LAST_EXE_TC_SUBTYPE=65535, HK_LFR_LAST_EXE_TC_TIME=0xffffffffffff, HK_LFR_LAST_REJ_TC_ID=0xffff, HK_LFR_LAST_REJ_TC_TYPE=65535, HK_LFR_LAST_REJ_TC_SUBTYPE=65535, HK_LFR_LAST_REJ_TC_TIME=0xffffffffffff, HK_LFR_LE_CNT=65535, HK_LFR_ME_CNT=65535, HK_LFR_HE_CNT=65535, /!\HK_LFR_LAST_ER_RID: 65535, /!\HK_LFR_LAST_ER_CODE: 255, HK_LFR_LAST_ER_TIME=0xffffffffffff, HK_LFR_VHDL_AA=15, HK_LFR_VHDL_SM=15, HK_LFR_VHDL_FFT=15, HK_LFR_VHDL_SR=15, HK_LFR_VHDL_CIC=15, HK_LFR_VHDL_HK=15, HK_LFR_VHDL_IIR=15, HK_LFR_VHDL_CAL=15, HK_LFR_DPU_SPW_PKT_RCV_CNT=65535, HK_LFR_DPU_SPW_PKT_SENT_CNT=65535, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=255, HK_LFR_LAST_FAIL_ADDR=0xffffffff, HK_LFR_TEMP_SCM=65535degC, HK_LFR_TEMP_PCB=65535degC, HK_LFR_TEMP_FPGA=65535degC, HK_LFR_SC_V_F3=65535, HK_LFR_SC_E1_F3=65535, HK_LFR_SC_E2_F3=65535, HK_LFR_DPU_SPW_PARITY=255, HK_LFR_DPU_SPW_DISCONNECT=255, HK_LFR_DPU_SPW_ESCAPE=255, HK_LFR_DPU_SPW_CREDIT=255, HK_LFR_DPU_SPW_WRITE_SYNC=255, HK_LFR_DPU_SPW_RX_AHB=255, HK_LFR_DPU_SPW_TX_AHB=255, HK_LFR_DPU_SPW_EARLY_EOP=255, HK_LFR_DPU_SPW_INVALID_ADDR=255, HK_LFR_DPU_SPW_EEP=255, HK_LFR_DPU_SPW_RX_TOO_BIG=255, HK_LFR_TIMECODE_ERRONEOUS=255, HK_LFR_TIMECODE_MISSING=255, HK_LFR_TIMECODE_INVALID=255, HK_LFR_TIME_TIMECODE_IT=255, HK_LFR_TIME_NOT_SYNCHRO=255, HK_LFR_TIME_TIMECODE_CTR=255, HK_LFR_BUFFER_DPU_TC_FIFO=255, HK_LFR_BUFFER_DPU_TM_FIFO=255, HK_LFR_AHB_CORRECTABLE=255, HK_LFR_AHB_UNCORRECTABLE=255, /!\SPARE=0xff

Pour le premier HK, les valeurs ne sont pas toutes reproductibles. Il est prévu d'avoir des octets à ff.
Pour le deuxième octet, le champ TIME devrait être à 0xffffffffffff.

Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.2.255
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.4 (variante sur carte finale)

TEST CASE = SVS-0011
Req = SSS-CP-FS-360

RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2


Related issues

Related to Bug #95: La durée du boot/reboot du LFR FSW semble mal maîtrisée.Closed2014-03-17

History

#1 Updated by paul leroy over 7 years ago

  • Status changed from New to Resolved
  • Assignee changed from paul leroy to bruno katra

fsw >= 1.0.0.6
Démarrage de la fonction HK légèrement modifié pour obtenir l'effet attendu: un paquet dummy HK est envoyé à la fin du boot. Il contient des paramètres fixés à 0xff. Le temps est le temps local.
Ce paquet peut-être utilisé pour mesurer le temps de boot.

IMPORTANT: l'émission du dummy HK devra être retirée avant la livraison du soft.

#2 Updated by Veronique bouzid over 7 years ago

Paul m'a montré la séquence d'init, il met le local_time à zero et juste avant la fin de la séquence d'init, il génere un paquet TM_LFR_HK.
Le champ TIME du paquet vaut TIME=0x800000000ea9 soit 0.05sec, durée de la séquence de boot.Le 8 indiquant que le paquet n est pas synchronisé.

Les champs listés ci-dessous contenus dans ce paquet spécifique (dummy HK) ont leurs bits positionnés à 1
- Section SOURCE_DATA/PARAMETERS/
HK_LFR_STATUS_WORD octet 17 et octet 18 positionnés à 0xFF
tous les champs à partir de RESOURCE_STATISTICS octet 26 --> fin positionnés à 0xFF

Ce format est vérifiable facilement dans le fichier nommé 2014_05_12-15_57_54-Tm.csv,
15:57:08.60291, 1, 2, 0, 0, 12, 196, 192, 0, 0, 117, 16, 3, 25, 0, 128, 0, 0, 0, 14, 169, 1, 255, 255, 1, 0, 0, 6, 0, 1, 9, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255

le champ TIME correspondant aux 6 octets 128, 0, 0, 0, 14, 169 --> 0x800000000ea9.

On voit que le paquet TM_LFR_HK suivant respecte le format de l'ICD
15:57:10.700212, 1, 2, 0, 0, 12, 196, 192, 1, 0, 117, 16, 3, 25, 0, 128, 0, 0, 2, 40, 53, 1, 13, 0, 1, 0, 0, 6, 0, 1, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
le champ TIME=0x800000022835 soit 2s environ, tjs pas de synchronisation

Ceci est conforme à ce que Paul a programmé.
Remarque
Le script qui affiche le détail des paquets remonte des warning sur l'analyse des champs
/!\HK_LFR_MODE: 15 --> [0,4]
/!\HK_LFR_DPU_SPW_LINK_STATE: 7 --> [0,5]
/!\SPARE=0x7 --> normalement = 0x0
/!\HK_LFR_RESET_CAUSE: 7 --> [0,5]
/!\HK_LFR_LAST_ER_RID: 65535 --> [0,42512]
/!\HK_LFR_LAST_ER_CODE: 255 --> [0,153]
/!\SPARE=0xff --> 0x0
C'est juste pour info, on ne modifiera pas le script pour prendre en compte ces valeurs, car ces dummy HK ne seront pas dans la livraison finale du software.

#3 Updated by bruno katra over 7 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF