Project

General

Profile

Actions

Bug #88

closed

CP_LFR_ENTER_MODE_TIME de TC_LFR_ENTER_MODE ignoré

Added by Gerald Saule over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
12/03/2014
Due date:
% Done:

0%

Estimated time:
Spent time:
revision:
r104

Description

Le champ CP_LFR_ENTER_MODE_TIME de TC_LFR_ENTER_MODE est toujours ignoré.
La transition vue semble immédiate.

17:58:32.947046, TM_LFR_HK, TIME=0x00000010cbe9, 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=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15

17:58:33.58306, TC_LFR_ENTER_MODE, CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000120000
17:58:33.600928, TM_LFR_TC_EXE_SUCCESS

17:58:33.947034, TM_LFR_HK, TIME=0x00000011cbe9, HK_LFR_MODE: STANDBY = 0

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.0.0.15
Soft: 1.0.0.2 (variante sur carte finale) = r104

Brique Brique Star-Dundee S/N 46120065.

TEST CASE associé(s) = SVS-0034.

RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1


Files

2014_05_16-12_48_12-Detail.txt (107 KB) 2014_05_16-12_48_12-Detail.txt bruno katra, 11/06/2014 05:00 PM
Actions #1

Updated by Gerald Saule over 10 years ago

Le rejet lorsque CP_LFR_ENTER_MODE_TIME<'temps interne' (SSS-CP-EQS-322) n'est également pas réalisé.

16:08:02.270435, TM_LFR_HK, TIME=*0x0000001d1f05*, HK_LFR_MODE: SBM2 = 4
16:08:02.952088, TC_LFR_ENTER_MODE, CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x0000001c0000
16:08:02.973026, TM_LFR_TC_EXE_SUCCESS
16:08:03.270756, TM_LFR_HK, TIME=0x0000001e1f05, HK_LFR_MODE: STANDBY = 0

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.0.15
Soft: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.

TEST CASE = SVS_0070

RPW-SYS-IDB-00067-LES_Issue1_Rev8
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1

Actions #2

Updated by paul leroy over 10 years ago

  • Status changed from New to Resolved

fsw >= 1.0.0.5
La fonction de commutation de mode à une date fixée est implémentée conformément à la SSS:
=> un mode erroné = TM_LFR_TC_EXE_INCONSISTENT
=> une transition non autorisée = TM_LFR_TC_EXE_NOT_EXECUTABLE
=> une date inférieure ou égale au temps courant = TM_LFR_TC_EXE_INCONSISTENT
=> une date valant 0 = transition immédiate
=> une date postérieure de plus de 3 secondes à la date courante = TM_LFR_TC_EXE_INCONSISTENT
=> toute autre date entraîne la transition à la date demandée

Actions #3

Updated by paul leroy over 10 years ago

  • Assignee changed from paul leroy to bruno katra
Actions #4

Updated by Veronique bouzid over 10 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from bruno katra to paul leroy

Ce point est tjs d'actualité avec la version Soft: 1.0.0.6 (variante sur carte finale).
PRECISION: Je ne parle que des TM_LFR_HK.

En rejouant le test SVS-0034, j'ai pu observé qu'effectivement ce point n'etait tjs pas résolu.
J ai donc ecrit un test plus simple qui demande
- une commutation de mode t+1s
- une commutation de mode t+2s
- une commutation de mode t+3s

Pour vérifier le dysfonctionnement, voir le fichier 2014_05_16-12_48_12-Detail.txt (en PJ)

Ici la trace t+2s, on voit bien que le bloc de HK montre deja la communication de mode avant la date demandée.

12:47:48.978489, TM_LFR_HK,TIME=0x800000043a18, HK_LFR_MODE: SBM2 = 4

12:47:49.776147, TC_LFR_ENTER_MODE (CP_LFR_MODE=0),
CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x000000060000,

12:47:49.796455, TM_LFR_TC_EXE_SUCCESS,TIME=0x800000050bc0

12:47:49.978485, TM_LFR_HK,TIME=0x800000053a19, HK_LFR_MODE: STANDBY = 0
HK_LFR_LAST_EXE_TC_TIME=0x800000050bc0 ( correspond à TM_LFR_TC_EXE_SUCCESS)

La commutation de mode a été effective dans la foulée.

Contexte:
LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f

Carte mini-LFR: LFR-172200 dev V1.0; No série 5
Vhdl: 0.0.16
Soft: 1.0.0.6 (variante sur carte finale)

Brique Star-Dundee S/N XX.
Script utilisé
SVS-0034/just_tm_hk.py

Actions #6

Updated by paul leroy over 10 years ago

  • Assignee changed from paul leroy to Veronique bouzid

Le fonctionnement précis du changement de mode est le suivant:
Si la TC est correcte
1) on arrête le mode en cours immédiatement
2) on redémarre les tâches temps réel avec les paramètres du nouveau mode
3) on configure le hardware pour qu'il démarre l'acquisition à la date fixée
4) à la fin de ces étapes, LFR est officiellement dans le mode, ce que reflètent les HK. C'est l'acquisition proprement dite qui commencera à CP_LFR_ENTER_MODE_TIME. On considère que LFR a changé de mode à la fin de la préparation complète du-dit mode.

C'est quelquechose dont j'avais parlé avec Gérald et ça nous paraissait la façon la plus appropriée de procéder. Il faudrait peut-être mettre à jour la SRS pour préciser le fonctionnement.

Pour finit, le juge pour une commutation réussie est la datation des données scientifiques, notamment les waveforms, qui doit être liée à CP_LFR_ENTER_MODE_TIME. C'est un des points à vérifier.

Actions #7

Updated by Veronique bouzid over 10 years ago

Hello,
Il ne faut donc pas utiliser les TM_LFR_HK pour valider le changement de mode à un temps.
Le pt #118 concerne egalement la validation du chgt de mode à un temps temps et la méthode
pour valider ce chgt utile les CWF du mode 3 sur les conseils de Paul.

Ok pour préciser dans la SRS les arguments de Paul.

Actions #8

Updated by bruno katra over 10 years ago

  • Status changed from Feedback to Closed

SRS mise à jour avec les informations de Paul sur la façon de valider un changement de mode (REQ-LFR-SRS-5509_Ed1 dans SRS 1.6+).

Actions

Also available in: Atom PDF