Bug #112
closed
Pb de traitement de TC_LFR_UPDATE_TIME
Description
Cette issue est proche de l'issue Bug #111 "Pb de timing dans le traitement de TC_LFR_UPDATE_TIME" (https://hephaistos.lpp.polytechnique.fr/redmine/issues/111).
Le changement de temps interne (au LFR) doit se faire sur réception du time code.
Par le code Python, on envoie TC_LFR_UPDATE_TIME, puis le time code 300ms après.
On a les traces:
11:27:07.425725, TM_LFR_HK, TIME=0x800001a9d100, HK_LFR_MODE: NORMAL = 1, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=4, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=2, SY_LFR_FPGA_VERSION_N3=255, HK_LFR_UPDATE_TIME_TC_CNT=0
11:27:08.216787, TC_LFR_UPDATE_TIME, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=10031, (PACKET_SEQUENCE_CONTROL=0xe72f), PACKET_LENGTH=11, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: TIME_MANAGEMENT = 9, SERVICE_SUBTYPE: UPDATE_TIME = 129, SOURCE_ID: MISSION_TIMELINE = 110, CP_RPW_TIME=0x000000000000, CRC = 0xd077
11:27:08.425752, TM_LFR_HK, TIME=0x800001aad102, HK_LFR_UPDATE_TIME_TC_CNT=1
11:27:09.425739, TM_LFR_HK, TIME=0x800001abd108
11:27:10.425739, TM_LFR_HK, TIME=0x800001acd102
11:27:11.425739, TM_LFR_HK, TIME=0x800001add103
CP_RPW_TIME n'est pas pris en compte.
Le pb n'apparaît pas dans la suite du script, lorsque sont testés les modes BURST,SBM1,SBM2,puis STANDBY.
(pour info, c'est ici avec le premier envoi de time code que le pb apparaît).
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.2.255
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.4 (variante sur carte finale)
TEST CASE = SVS-0011
Req = SSS-CP-FS-360
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Updated by Gerald Saule over 10 years ago
- revision changed from r110 to r114
La contre-manip décrite ci-dessous montre que le pb se reproduit de façon aléatoire.
L'initialisation du traitement des TC_LFR_UPDATE_TIMEs et time code ne semble pas en cause.
Le mode courant lorsqu'un retard non maîtrisé ne semble pas lié à l'apparition de ce retard (il y a peut-être un coïncidence autour du mode STANDBY).
############################################################################
Demarrage de:
-Driver brick
-boot carte
-Lppmon
-soft de validation (python)
############################################################################
(STANDBY)
11:22:38.715599, TM_LFR_HK, HK_LFR_UPDATE_TIME_TC_CNT=1
11:22:38.740835, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x5a93c1850000
11:22:39.04124,Time code sent
11:22:39.715484, TM_LFR_HK, TIME=0x5a93c185ac24, HK_LFR_UPDATE_TIME_TC_CNT=1
11:22:39.715484 - 11:22:39.04124 = 0,674244s
0x5a93c185ac24 - 0x5a93c1850000 = 0,672424316
DELTA=1.819684ms
(NORMAL)
11:22:43.06646, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x40da673c0000
11:22:43.36714,Time code sent
11:22:43.715736, TM_LFR_HK, TIME=0x40da673c58ba
11:22:43.715736 - 11:22:43.36714 = 0,348596
0x40da673c58ba - 0x40da673c0000 = 0,346588135
DELTA=2.007865ms
(BURST)
11:22:47.391053, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x347945940000
11:22:47.691679,Time code sent
11:22:47.71604, TM_LFR_HK, TIME=0x3479459405a9
11:22:47.71604 - 11:22:47.691679 = 0,024361s
0x3479459405a9 - 0x347945940000 = 0,022109985 s
DELTA=2.251015ms
(SBM1)
11:22:51.722875, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x3ee391530000
...
11:22:51.753425, TM_LFR_HK, TIME=0x3479459805ac
11:22:52.023203,Time code sent
...
11:22:52.716024, TM_LFR_HK, TIME=0x3ee39153b0cb
11:22:52.716024 - 11:22:52.023203 = 0,692821s
0x3ee39153b0cb - 0x3ee391530000 = 0,690597534s
DELTA=2.223466ms
(SBM2)
*> 11:22:55.715567, TM_LFR_HK
11:22:56.050839, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x30e733fe0000
11:22:56.351124,Time code sent
11:22:56.742403, TM_LFR_HK, TIME=0x30e733fe5cd9*
11:22:56.742403 - 11:22:56.351124 = 0,391279s
0x30e733fe5cd9 - 0x30e733fe0000 = 0,362686157s
DELTA=28.592843ms
############################################################################
Sans démarrage de:
-Driver brick
-boot carte
-Lppmon
Demarrage de:
-soft de validation (python)
############################################################################
(STANDBY)
*> 11:25:48.569646, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x3328518b0000
11:25:48.869901,Time code sent
11:25:48.716993, TM_LFR_HK, TIME=0xb0e734aa5d44, HK_LFR_UPDATE_TIME_TC_CNT=12
11:25:49.716233, TM_LFR_HK, TIME=0x3328518bd840
*11:25:49.716233 - 11:25:48.869901 = 0,99924s
0x3328518bd840 - 0x3328518b0000 = 0,844726563
DELTA=154.513437ms
(NORMAL)
11:25:52.893553, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x3c6bfc780000
11:25:53.193809,Time code sent
11:25:53.716421, TM_LFR_HK, TIME=0x3c6bfc788555
11:25:53.716421 - 11:25:53.193809 = 0,522612s
0x3c6bfc788555 - 0x3c6bfc780000 = 0,520828247 s
DELTA=1.783753ms
(BURST)
11:25:57.217835, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x721f18180000
11:25:57.518101,Time code sent
11:25:57.716386, TM_LFR_HK, TIME=0x721f18183251
11:25:57.716386 - 11:25:57.518101 = 0,198285
0x721f18183251 - 0x721f18180000 = 0,196548462
DELTA=1.736538ms
(SBM1)
11:26:01.549259, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x0aec6b850000, CRC = 0x70c6
...
11:26:01.849495,Time code sent
...
11:26:02.717043, TM_LFR_HK, TIME=0x0aec6b85dd7c
11:26:02.717043 - 11:26:01.849495 = 0,867548
0x0aec6b85dd7c - 0x0aec6b850000 = 0,86517334
DELTA=2.37466ms
(SBM2)
11:26:05.872389, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x477d6ceb0000
11:26:06.172659,Time code sent
11:26:06.716956, TM_LFR_HK, TIME=0x477d6ceb8ac7
11:26:06.716956 - 11:26:06.172659 = 0,544297s
0x477d6ceb8ac7 - 0x477d6ceb0000 = 0,542098999s
DELTA=2.198001ms
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.1.9
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.5 (variante sur carte finale)
TEST CASE = SVS-0013
Req = s.o.
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Updated by paul leroy over 10 years ago
- Status changed from New to Feedback
- Assignee changed from paul leroy to bruno katra
Pour clore l'issue, il faudrait relancer ces tests avec fsw >= 1.0.0.8 et VHDL >= x.1.16, l'état du système a trop évolué pour poser un diagnostique clair en l'état actuel des choses.
Updated by Veronique bouzid over 10 years ago
les 2 tests on été relancés
- SVS-0011 (traces dans le fichier 2014_06_12-15_42_11-Detail.txt)
On voit bien l application du temps et le compteur qui s incremente
TM_LFR_HK TIME=0x800000146f89 HK_LFR_UPDATE_TIME_TC_CNT=0
TM_LFR_HK TIME=0x000000001cb5 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000011cb6 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000021cb5 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000031cb2 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000042229 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x0000000522f5 HK_LFR_UPDATE_TIME_TC_CNT=2
TM_LFR_HK TIME=0x00000000cf8b HK_LFR_UPDATE_TIME_TC_CNT=2 -- TC_LFR_DATE_TIME avec CP_RPW_TIME=0x000000000000 +TimeCode
Avec la trace des données scientifiques (UPDATE_TIME + Timecode à 15:41:51.321852)
15:41:51.021507, TC_LFR_UPDATE_TIME,CP_RPW_TIME=0x000000000000
15:41:51.093125, TM_LFR_SCIENCE_BURST_BP1_F0,TIME=0x000000050e33 --Ici le Time code n est pas arrivé
15:41:51.113247, TM_LFR_SCIENCE_BURST_BP1_F1,TIME=0x0000000517c4
15:41:52.086791, TM_LFR_SCIENCE_BURST_BP1_F0,*TIME=0x00000000b9de* L update time a ete appliqué
Remarque
La commande TC_LFR_UPDATE_TIME entraine l increment du champ HK_LFR_UPDATE_TIME_TC_CNT de la TM_LFR_HK (sans attendre le timecode) mais pas de mise à jour des
HK_LFR_LAST_EXE_TC_ID,HK_LFR_LAST_EXE_TC_TYPE,HK_LFR_LAST_EXE_TC_SUBTYPE,HK_LFR_LAST_EXE_TC_TIME.
C'est normal dixit Paul et effectivement cette commande n est pas acceptée et executée.
- SVS-0013
l'Analyse des traces de chacun des modes joués (normal, burst, sbm1,sbm2) est correcte.
Dans ce test, les cdes UPDATE_TIME envoyés avancent dans le temps. Toutes sont prises en compte
ici un exemple sur le normal mode
mode 1
15:44:37.056398, TC_LFR_UPDATE_TIME,CP_RPW_TIME=0x7df510310000
15:44:37.434299, TM_LFR_HK, TIME=0x5d7d9af44c94, HK_LFR_UPDATE_TIME_TC_CNT=3
15:44:38.057541, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x020aefce0000
15:44:38.35786,Time code sent
15:44:38.458532, TM_LFR_HK,TIME=0x020aefce12f1, HK_LFR_UPDATE_TIME_TC_CNT=4
15:44:40.120517, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x020aefcfb994
Il reste à valider le mode Standby
-------------------------------------------------------------
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.1.16
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.8 (variante sur carte finale)
TEST CASE = SVS-0013
Req = s.o.
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Updated by Veronique bouzid over 10 years ago
Veronique bouzid wrote:
les 2 tests on été relancés
- SVS-0011 (traces dans le fichier 2014_06_12-15_42_11-Detail.txt)
On voit bien l application du temps et le compteur qui s incremente
TM_LFR_HK TIME=0x800000146f89 HK_LFR_UPDATE_TIME_TC_CNT=0
TM_LFR_HK TIME=0x000000001cb5 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000011cb6 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000021cb5 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000031cb2 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x000000042229 HK_LFR_UPDATE_TIME_TC_CNT=1
TM_LFR_HK TIME=0x0000000522f5 HK_LFR_UPDATE_TIME_TC_CNT=2
TM_LFR_HK TIME=0x00000000cf8b HK_LFR_UPDATE_TIME_TC_CNT=2 -- TC_LFR_DATE_TIME avec CP_RPW_TIME=0x000000000000 +TimeCodeAvec la trace des données scientifiques (UPDATE_TIME + Timecode à 15:41:51.321852)
15:41:51.021507, TC_LFR_UPDATE_TIME,CP_RPW_TIME=0x000000000000
15:41:51.093125, TM_LFR_SCIENCE_BURST_BP1_F0,TIME=0x000000050e33 --Ici le Time code n est pas arrivé
15:41:51.113247, TM_LFR_SCIENCE_BURST_BP1_F1,TIME=0x0000000517c4
15:41:52.086791, TM_LFR_SCIENCE_BURST_BP1_F0,*TIME=0x00000000b9de* L update time a ete appliqué1- Remarque
La commande TC_LFR_UPDATE_TIME entraine l increment du champ HK_LFR_UPDATE_TIME_TC_CNT de la TM_LFR_HK (sans attendre le timecode) mais pas de mise à jour des
HK_LFR_LAST_EXE_TC_ID,HK_LFR_LAST_EXE_TC_TYPE,HK_LFR_LAST_EXE_TC_SUBTYPE,HK_LFR_LAST_EXE_TC_TIME.
C'est normal dixit Paul et effectivement cette commande n est pas acceptée et executée.
2- Remarque
Le test SVS-011 a été modifié pour supprimer l utilisation de la TC_LFR_RESET et à la place, on passe en mode Standby à la fin de chaque changement de mode.
De plus, j ai ajouté un step qui en mode standby attend 61 sec pour vérifier la perte de synchronisation.
- SVS-0013
l'Analyse des traces de chacun des modes joués (normal, burst, sbm1,sbm2) est correcte.
Dans ce test, les cdes UPDATE_TIME envoyés avancent dans le temps. Toutes sont prises en compte
ici un exemple sur le normal mode
mode 1
15:44:37.056398, TC_LFR_UPDATE_TIME,CP_RPW_TIME=0x7df51031000015:44:37.434299, TM_LFR_HK, TIME=0x5d7d9af44c94, HK_LFR_UPDATE_TIME_TC_CNT=3
15:44:38.057541, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x020aefce0000
15:44:38.35786,Time code sent
15:44:38.458532, TM_LFR_HK,TIME=0x020aefce12f1, HK_LFR_UPDATE_TIME_TC_CNT=415:44:40.120517, TM_LFR_SCIENCE_NORMAL_BP1_F0, TIME=0x020aefcfb994
Il reste à valider le mode Standby
-------------------------------------------------------------
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.1.16
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.8 (variante sur carte finale)TEST CASE = SVS-0013
Req = s.o.RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Updated by bruno katra over 7 years ago
- Status changed from Feedback to Closed
A la relecture des commentaires : lepb semble corrigé