Project

General

Profile

Actions

Bug #112

closed

Pb de traitement de TC_LFR_UPDATE_TIME

Added by Gerald Saule almost 10 years ago. Updated almost 7 years ago.

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

0%

Estimated time:
Spent time:
revision:
r114

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

Actions #1

Updated by Gerald Saule almost 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

Actions #2

Updated by paul leroy almost 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.

Actions #3

Updated by Veronique bouzid almost 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

Actions #4

Updated by Veronique bouzid almost 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 +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é

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=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

Actions #5

Updated by bruno katra almost 7 years ago

  • Status changed from Feedback to Closed

A la relecture des commentaires : lepb semble corrigé

Actions

Also available in: Atom PDF