Project

General

Profile

Actions

Bug #604

closed

Nominal : TC_LFR_UPDATE_TIME + Time-code does'n t work

Added by Veronique bouzid about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
High
Category:
-
Target version:
-
Start date:
02/02/2016
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Pour valider le fonctionnement nominal du CTR message emis par le DPU et sans utiliser le timegen, j'ai écrit un script
(,/opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0011/starting_time_set_time.py)
qui juste après la sequence de boot déroule le scénario suivant

0 - Lecture du registre contenant la valeur du Time-code (registre 0x80000514 = TIMECNT = 0)
1- Récuperation du temps actuel
2- Generation d' une TC_LFR_UPDATE_TIME avec ce temps
3- calcule du timecode en extrayantles 6bits de poins faibles du champ CP_RPW_TIME
4 Envoi de TC_UPDATE_TIME
5 Envoi du time-code 0.3s apres

Résultat : La TC_LFR_UPDATE n'est pas prise en compte, le time-code envoyé n'a pas été validé et donc pas de tick-out.

12:42:06.118198, TM_LFR_HK, TIME=0x80000004439a, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0

12:42:06.964825,* TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1e43609e0000*

12:42:07.11826, TM_LFR_HK, TIME=0x80000005439a, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=

12:42:08.11836, TM_LFR_HK, TIME=0x80000006439a, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0

Paul, je sais que tu as dit qu'il fallait envoyer plusieurs time-codes mais en integration, cela m'etonne que le DPU se comporte comme cela.

Il faut donc etre capable de démarrer correctement en envoyant le bon time-code , est ce que le probleme ne viendrait pas du soc explorer qui ne nous permet
pas de démarrer à n'importe quelle valeur.

SI je fais le même test en envoyant le time-code = 1 (car la valeur initiale du registre est 0), la TC_LFR_UPDATE_TIME est prise en compte et
le champ HK_LFR_TIME_TIMECODE_CTR = 1 mais c'est normal puisqu'il ne correspond pas aux 6bits du champ.

Les fichiers de test (2016_02_02_12_42*) sont dans le répertoire /home/validation/data/R3/3.0.0.15/TESTS-UNITAIRES/my_time/nominal

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

Actions

Also available in: Atom PDF