Bug #591
closed
HK_LFR_TIME_NOT_SYNCHRO stays to 1
0%
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
Updated by Veronique bouzid almost 9 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
Updated by paul leroy almost 9 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
Updated by Veronique bouzid almost 9 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??
Updated by paul leroy almost 9 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.
Updated by Veronique bouzid almost 9 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