Project

General

Profile

Actions

Bug #113

closed

Affectation des champs de TM_LFR_HK en fin de boot du LFR

Added by Gerald Saule almost 8 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.Closedbruno katra17/03/2014

Actions
Actions #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.

Actions #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.

Actions #3

Updated by bruno katra over 7 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF