Project

General

Profile

Actions

Bug #591

closed

HK_LFR_TIME_NOT_SYNCHRO stays to 1

Added by Veronique bouzid over 8 years ago. Updated over 8 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

Actions

Also available in: Atom PDF