Bug #118
closed
TC_LFR_ENTER_MODE: prise en compte de CP_LFR_ENTER_MODE_TIME
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
Updated by Gerald Saule over 10 years ago
TEST CASE = SVS-0034; SVS-0070/LfrEnterModeTime
Updated by paul leroy over 10 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.
Updated by Veronique bouzid over 10 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