Project

General

Profile

Bug #591

HK_LFR_TIME_NOT_SYNCHRO stays to 1

Added by Veronique bouzid almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
25/01/2016
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Après la sequence de boot, LFR n'est pas synchronisé, sur les premiers blocs de TM_LFR_HK on observe donc
- le bit B0 du champ TIME = 1 (
- le champ HK_LFR_TIME_NOT_SYNCHRO positionné à 1

J'envoie un couple TC_LFR_UPDATE_TIME et le time-code qui va bien , je vérifie que LFR est bien synchronisé

- le champ TIME de TM_LFR_HK correspond à la valeur CP_RPW_TIME (0x5Cff66010000
- le champ HK_LFR_DPU_SPW_TICK_OUT_CNT est incrémenté de 1
- le champ HK_LFR_DPU_SPW_LAST_TIMC = 1 (valeur du time-code envoyé)
- le champ HK_LFR_TIME_NOT_SYNCHRO est resté à 1
- le champ HK_LFR_LE_CNT n'a pas été incrémenté ( il est donc resté à 1)

--> On a LFR synchronisé donc POURQUOI HK_LFR_TIME_NOT_SYNCHRO n'est pas passé à 0

Les fichiers de test (2016_01_25-10_23_40*) se trouvent dans /home/validation/data/R3/3.0.0.13/1.1.89/SVS-0012/

Voici un extrait des logs décrivant la sequence et les observations
10:20:27.224101, TM_LFR_HK, TIME=0x8000000a36d3
, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:28.223976, TM_LFR_HK, TIME=0x8000000b36d3, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0
----
10:20:30.224019, TM_LFR_HK, TIME=0x8000000d36d3, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:30.752525, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x5cff66010000

10:20:31.223965, TM_LFR_HK, TIME=0x5cff66012a99, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

1*0:20:32.223982, TM_LFR_HK, TIME=0x5cff66022718*, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_LE_CNT=2, 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=1, HK_LFR_TIME_TIMECODE_CTR=1

--> le champ HK_LFR_TIME_TIMECODE_CTR=1 est du au fait que je n'envoie plus que des time-code (sans TC_LFR_UPDATE_TIME).

Le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0012/ccsds_time_code_format.py

Contexte du test
----------------------
FSW 3.0.0.13
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

History

#1 Updated by Veronique bouzid almost 6 years ago

Je viens de me rendre compte que le champ HK_LFR_TIME_NOT_SYNCHRO est un compteur et non un cchamp de statut. (0= SYNCHRO, 1= NON SYNCHRO)

Donc le champ HK_LFR_TIME_NOT_SYNCHRO doit s'incrémenter à chaque TM_LFR_HK . Il est donc faux puisqu'il reste à 1 tant que la commande TC_LFR_UPDATE_TIME + time-code n'a pas été envoyée.

10:20:27.224101, TM_LFR_HK, TIME=0x8000000a36d3, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:28.223976, TM_LFR_HK, TIME=0x8000000b36d3, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:29.224126, TM_LFR_HK, TIME=0x8000000c36d4, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:30.224019, TM_LFR_HK, TIME=0x8000000d36d3, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:30.752525, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x5cff66010000

--> A partir de la, il ne doit plus s'incrementer

10:20:31.223965, TM_LFR_HK, TIME=0x5cff66012a99, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_LE_CNT=1, 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=1, HK_LFR_TIME_TIMECODE_CTR=0

10:20:32.223982, TM_LFR_HK, TIME=0x5cff66022718, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_LE_CNT=2, 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=1, HK_LFR_TIME_TIMECODE_CTR=1
10:20:33.224022, TM_LFR_HK, TIME=0x5cff66032458, HK_LFR_DPU_SPW_TICK_OUT_CNT=3, HK_LFR_DPU_SPW_LAST_TIMC=3, HK_LFR_LE_CNT=3, 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=1, HK_LFR_TIME_TIMECODE_CTR=2

#2 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid

Pour moi, le champ reflète la perte de la synchro, c'est à dire le passage de 0 à 1 du bit 31 du coarse_time. A mon avis, c'est conforme à la définition que j'ai trouvée pour le comportement côté DPU:

HK_LFR_TIME_NOT_SYNCHRO
The DPU has lost synchronization.
The synchronization bit was set to one. Note : this error occurs when no SpaceWire time code is received by the DPU Flight Software for a period greater than SY_RPW_DELAY_WITHOUT_CTR = 60 seconds

#3 Updated by Veronique bouzid almost 6 years ago

  • Assignee changed from Veronique bouzid to paul leroy

Je suis d'accord avec cette analyse mais cela ne me dit pas si tu le consideres comme un compteur,c'est à dire qu'à chaque perte de synchro tu vas incrementer le champ.

Ensuite dans la doc DPU il est bien écrit que la perte de synchro est lié à l'absence de time-code durant 60s.
The synchronization bit was set to one. Note : this error occurs when no SpaceWire time code is received by the DPU Flight Software for a period greater than SY_RPW_DELAY_WITHOUT_CTR = 60 seconds.

1- Après la sequence de boot, tu ne dois pas mettre à jour le champ HK_LFR_TIME_NOT_SYNCHRO
2- Pour que nous soyons synchronisé, il faut imperativement une sequence correcte (TC_LFR_UPDATE_TIME + time-code) donc tant que nous n'avons pas cela, le bit 31 est positionné à 1 et toi tu traduis cela comment??

#4 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid

C'est un compteur du nombre de transition synchronisé (bit 31 à 0) vers désynchronisé (bit 31 à 1).

On commence désynchronisé, bit 31 à 1, et puis on attend la première désynchronisation pour incrémenter le compteur (passage du bit 31 de 0 à 1). Une fois désynchronisé, le compteur ne bouge plus jusqu'à la prochaine perte de synchro.

#5 Updated by Veronique bouzid almost 6 years ago

  • Status changed from New to Closed

En version 3.0.0.14, après la sequence de boot, Paul met le HK_LFR_TIME_NOT_SYNCHRO à ZERO.

le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0011/starting_time.py

les fichiers (2016_01_27-08_44_05-*) se trouvent dans le répertoire /home/validation/data/R3/3.0.0.14/1.1.89/SVS-0011.

Un extrait du fichier 2016_01_27-08_44_05-Detail.txt après la séquence de boot

08:43:45.808831, 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=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=0x8000000243b0, 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, 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=14, SY_LFR_FPGA_VERSION_N1=1, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=89, HK_LFR_CPU_LOAD=3.13725490196, HK_LFR_CPU_LOAD_MAX=3.13725490196, HK_LFR_CPU_LOAD_AVE=0.0, HK_LFR_Q_SD_FIFO_SIZE_MAX=0, HK_LFR_Q_SD_FIFO_SIZE=50, HK_LFR_Q_RV_FIFO_SIZE_MAX=0, HK_LFR_Q_RV_FIFO_SIZE=10, HK_LFR_Q_P0_FIFO_SIZE_MAX=0, HK_LFR_Q_P0_FIFO_SIZE=10, HK_LFR_Q_P1_FIFO_SIZE_MAX=0, HK_LFR_Q_P1_FIFO_SIZE=10, HK_LFR_Q_P2_FIFO_SIZE_MAX=0, 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=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=202.49degC, HK_LFR_TEMP_PCB=17.86degC, HK_LFR_TEMP_FPGA=20.16degC, HK_LFR_SC_V_F3=588, HK_LFR_SC_E1_F3=503, HK_LFR_SC_E2_F3=379, 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, 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

Contexte du test
----------------------
FSW 3.0.0.14
VHDL 1.1.89
EM sans timegen
SocExplorerEngine.get SocExplorer: Version = 0.6.2, Branch = defaukt, Changeset = 819d0376d481
StarDundee

Also available in: Atom PDF