Bug #356
closed
Mise au point Timegen sur EM
100%
Description
/!\ Issue copiée de #255 qui était en "planified" donc pas cloturable. #255 détruite depuis.
------------------------
Installation du code TImegen version 0.0.0.1 sur pc-coillot dans répertoire /opt/TIMEGEN
[validation@pc-coillot 2014_10_23]$ ls l /opt/TIMEGEN/ 1 validation validation 622 24 oct. 13:58 RELOAD_ALL_STAR_DUNDEE.py
total 3944
drwxrwxr-x 2 validation validation 4096 24 oct. 13:43 0.0.0.1
-rw-rw-r-rw-rw-r- 1 validation validation 4022648 26 sept. 08:16 RPW-MEB-LFR-NTT-00125-1-0_GSE_System_clock_simulator.odt
Le test a mis en évidence que la commande TC_UPDATE_TIME n'est pas prise en compte.
- Envoi des timecode OK (on utilise minicom -D /dev/ttyUSB3 (ou USB1)
Avec SocEXplorer, envoi de la commande TC_LFR_UPDATE_TIME, l affichage montre que le COARSE TIME n est pas mis à jour.
----------------------------------------------------------------------------
Contexte
LFR_FSW_PATH = /opt/LFR-FSW/2.0.1.1/fsw
Bridge selection = StarDundee
SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520
Carte EM: 1.1.26
Mini LFR : 0.1.25
Files
Updated by bruno katra about 9 years ago
- Description updated (diff)
- Status changed from New to Closed
Updated by paul leroy 3 days ago
Assignee changed from paul leroy to Veronique bouzid
Comment Edit
Si timegen est lancé, il envoie un paquet TC_LFR_UPDATE_TIME à LFR 700 ms après la réception de chaque timecode valide.
1) Tu envoies un paquet TC_LFR_UPDATE_TIME à LFR (spacewire link 1), mais que LFR est synchronisé par timegen, la synchro timegen prend le dessus. Il peut y avoir un aléat bizarre sur une seconde si tu envoies ton paquet avec lfrcontrolplugin au mauvais moment et qu'il écrase celui de timegen.
2) Tu envoies un paquet TC_LFR_UPDATE_TIME à timegen (spacewire link 2), il mets à jour son coarse time local et envoie des paquet TC_LFR_UPDATE_TIME actualisé à LFR: la date est mise à jour.
#2 Updated by Veronique bouzid 7 days ago
File 2015_2_27-12_4_8_packet_log.data added
Assignee changed from Veronique bouzid to paul leroy
% Done changed from 0 to 100Comment Edit
Voici le nouveau contexte de test opérationnel depuis debut 2015
- Timegen 0.0.0.1
- LFR-FSW 2.0.2.2 (VHDL = 1.1.63)
SocExplorerEngine.getSocExplorer: Version = 0.4.5, Branch = default, Changeset = c4b98d42ee59
Ouverture de Socexplorer
Lancement du script /opt/VALIDATION_R2//LFRControlPluginstartALL.py
On observe sur la fenetre LFRControlPlugin0 Onglet TM statitics
que le coarse time est bien initialisé à zero et s incremente de 1 . Cela correspond à la date de réference (2000/01/01)
Ensuite onglet dashboard
on envoie un TC_LFR_UPDATE_TIME (now) mais cela ne met pas à jour le coarse time.
Par contre si je glisse dans la console python le script (/opt/VALIDATION_R2/setTime.py qui envoie la commande TC_LFR_UPDATE_TIME avec la date du moment (now) cela fonctionne.
Le fichier de log montre que les HK s incremente correctement mmais que le temps envoyée par la cde TC_UPDATE_TIME n a pas été prise en compte.
Ici un extrait du fichier de log (/home/validation/data/2015_2_27-12_13_16_packet_log.data
qui correspond à l'utilisation du script setTime.py montrant la prise en compte de la mise à l heure
2015 2 27 12:13:24:823 TM_LFR_HK time = 0x 19 395
2015 2 27 12:13:25:824 TM_LFR_HK time = 0x 1a 394
2015 2 27 12:13:26:824 TM_LFR_HK time = 0x 1b 394
2015 2 27 12:13:27:823 TM_LFR_HK time = 0x 1c 393
2015 2 27 12:13:28:823 TM_LFR_HK time = 0x 1c831be8 393
2015 2 27 12:13:29:823 TM_LFR_HK time = 0x 1c831be9 392
2015 2 27 12:13:30:823 TM_LFR_HK time = 0x 1c831bea 391
2015 2 27 12:13:31:823 TM_LFR_HK time = 0x 1c831beb 391
2015 2 27 12:13:32:823 TM_LFR_HK time = 0x 1c831bec 390
#1 Updated by paul leroy 29 days ago
Assignee changed from paul leroy to Veronique bouzidComment Edit
Rejouer les tests sur FSW >= 2.0.2.1 et VHDL >= x.1.57