Bug #604
closed
Nominal : TC_LFR_UPDATE_TIME + Time-code does'n t work
0%
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
Updated by paul leroy about 8 years ago
LFR doit recevoir plusieurs timecodes valide avant de commencer à les accepter, ce que fait le DPU puisqu'il n'envoie que des timecodes valides normalement (incrément de 1 entre deux timecodes). L'IP SpaceWire de LFR n'est remise à zéro que au démarrage de la carte. Le dernier timecode valide est gardé par l'IP SpaceWire qui attend d'en avoir d'autres valides.
Je pense qu'on peut utiliser timegen pour faire le test que tu veux, il n'y a pas de problème avec SocExplorer, il fait ce qu'on lui dit.
Quelques pistes:
SpwPlugin0.StarDundeeSendOneTimecode() permet d'envoyer le timecode qu'on veut. Ensuite SpwPlugin0.StarDundeeStartTimecodes(1) permet de démarrer les timecodes à 1 Hz, à partir de la dernière valeur que tu as demandé avec SpwPlugin0.StarDundeeSendOneTimecode().
Updated by paul leroy about 8 years ago
- Assignee changed from paul leroy to Veronique bouzid
Updated by Veronique bouzid about 8 years ago
- Status changed from New to Closed
pas de solution. Je clos et on attend de voir avec les tests d'intégration au LESIA.