Project

General

Profile

Bug #118

TC_LFR_ENTER_MODE: prise en compte de CP_LFR_ENTER_MODE_TIME

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

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

0%

Estimated time:
Spent time:
revision:
r114

Description

CP_LFR_ENTER_MODE_TIME n'est actuellement pas prise en compte correctement:

10:23:31.251123, TM_LFR_HK, TIME=0x0000020844d5, HK_LFR_MODE: SBM2 = 4, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=5, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=9
10:23:31.983833, TC_LFR_ENTER_MODE (CP_LFR_MODE=0), CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x0000020a0000
10:23:32.001456, TM_LFR_TC_EXE_SUCCESS
10:23:32.251109, TM_LFR_HK, TIME=0x0000020944db, HK_LFR_MODE: STANDBY = 0

La transition ne doit être immédiate que si CP_LFR_ENTER_MODE_TIME=0x000000000000.

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-0034
Req = REQ-LFR-SRS-5509/SSS-CP-FS-320

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

History

#1 Updated by Gerald Saule over 7 years ago

TEST CASE = SVS-0034; SVS-0070/LfrEnterModeTime

#2 Updated by paul leroy over 7 years ago

  • Status changed from New to Resolved
  • Assignee set to bruno katra

fsw >= 1.0.0.6

cp_lfr_enter_mode_time = 0 => commutation immédiate

Les autres contraintes sont respectées. Relancer les tests sur la version mise à jour du soft de vol.

#3 Updated by Veronique bouzid over 7 years ago

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

Ce point traduit le meme pb de commutation de mode à date fixe.
Le test SVS-0034 a été rejoué.

- La commutation de mode instantanée est validée
- La commutation de mode à une date donnée pour les TM_LFR_HK n'est pas corrigée (voir pt #88)

Pour vérifier la commutation de mode pour les données, Paul m a conseillé d'utiliser par exemple le mode SBM1 qui génére
rapidement des produits CWF. On pourra donc vérifier que TIME du premier echantillon du CWF est postérieur à la demande de changement de mode.

De meme, j ai écrit un petit script pour valider ce scénario (vero.py dans SVS-0034)
- une commutation t+3s
mode 4 instantané vers mode 3 à t+3s vers mode 0 à t+3s

10:55:28.479763, TM_LFR_HK, TIME=0x800000033a1a,HK_LFR_MODE: SBM2 = 4

10:55:29.119796, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)
CP_LFR_MODE: SBM1 = 3, CP_LFR_ENTER_MODE_TIME=0x000000060000

10:55:29.140685, TM_LFR_TC_EXE_SUCCESS, TIME=0x80000003e3b7

10:55:29.503716, TM_LFR_HK,TIME=0x800000044061, HK_LFR_MODE: SBM1 = 3 --CONFIRME #88

10:55:29.703726, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x800000046b9a -- Bug expliqué par Paul (

10:55:29.928762, TM_LFR_SCIENCE_SBM1_BP1_F0,TIME=0x80000004eb9f -- idem
cela continue jusqu'a

10:55:31.958613, TM_LFR_SCIENCE_SBM1_CWF_F1,TIME=0x80000006000c = PA_LFR_ACQUISITION_TIME=0x80000006000c

On voit bien que la commutation de mode demandée à CP_LFR_ENTER_MODE_TIME=0x000000060000 est mise en évidence par le temps du 1er échantillon du produit CWF
soit 0x80000006000c.

AU sujet des BP, Paul a donné l'explication:
Actuellement c'est un simulateur qui génère les BP et il ne prend pas en compte la commutation de mode à un temps.
J'ouvre donc un pt redmine pour qu'une fois les BP intégrés, on valide à nouveau le TEST SVS-0034 écrit par Gérald.

Je ferme ce point car en rejouant le test SVS-0034, j ai vérifié à l'aide des CWF que la commutation de mode à un temps donné fonctionnait
et respectait les regles:
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

Also available in: Atom PDF