Bug #95
closed
La durée du boot/reboot du LFR FSW semble mal maîtrisée.
0%
Description
(Cette issue reprend Bug #698 "La durée du boot du LFR FSW semble trop longue" de pc-instru).
Le pluggin dsu3plugin permet d'affiner les steps de validation.
On a parfois des traces cohérentes avec le timing ci-dessous:
Boot
16:30:40.804085,FSW run() done.
16:30:41.040005, TM_LFR_HK
Reboot
16:30:56.23221,FSW run() done.
16:30:56.467706, TM_LFR_HK
Mais la réception d'un TC juste après le boot peut retarder sensiblement l'arrivée de la première TM:
16:24:15.690052,FSW run() done.
16:24:16.192459, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)
16:24:17.918191, TM_LFR_HK
La durée max est SY_LFR_DELAY_ACC_TC (500ms actuellement).
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_0054
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Related issues
Updated by paul leroy over 10 years ago
- Status changed from New to Resolved
fsw >= 1.0.0.4
pour la mesure du temps de boot, un paquet HK est émis à la fin du boot avec tous les octets à 0xff hormis la révision du soft et la version du VHDL.
Updated by paul leroy over 10 years ago
- Assignee changed from paul leroy to bruno katra
Updated by bruno katra over 10 years ago
- Status changed from Resolved to Closed
Cela semble maintenant stable : mail Véro :
hello,
Pour info sur l'EM, le temps de boot varie entre 0x12c4 à 0x12cd (fine time) avec VHDL=1.0.23
Sur la carte minilfr,
on etait entre 0x0ea9 avec VHDL 0.0.16
on est à 0x12ca avec VHDL 0.0.23.
Véronique