LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Vérification effectuée sur EQM avec 2.1.83 et MINI-LFR avec design 0.1.68, le tout premier buffer CWF_F3 a une date 0x00000000, bien que les données paraissent correctes.

Les autres buffers sont correctement datés.

Le temps du premier buffer a CWF_F3 (premiere salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3) ont une date a 0x00000000.

Ce bug est toujours present dans le design 1.1.89, et le seras aussi sur le design 3.1.89.

Une alternative software est envisageable soit au niveau de LFR, soit au niveau du post traitement des donnees sur terre. En effet, ce temps d'acquisition est "normalement" le temps de declanchement de l'acquisition. Il peut aussi etre deduit du temps des datas de la deuxieme salve de 4 TM_LFR_SCIENCE_NORMAL_CWF_F3.

Suite à l'installation du LFR-SFW version 3.0.0.13, l'analyse montre que le timing des CWF_F3 en normal mode est correct.

Plusieurs tests ont été menés et donnent toujours la même conclusion: Le timing est correct.

1- Lancement du script /home/validation/SCRIPT/R3/normal_vs_sbm1_mode.py
Ce script demarre en normal mode durant 800s puis communte en SBM1 durant 800s.

Voici les CWF_F3 générées
08:25:02.877994, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)
08:25:02.895228, TM_LFR_TC_EXE_SUCCESS,* TIME=0x8000000b6c75*

la premiere salve de CWF_F3 au timing parfait,
08:27:51.437307, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000000bf2a1
08:27:51.445328, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000035f2a1
08:27:51.459338, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000005ff2a1
08:27:51.47251, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000089f2a1

la deuxieme salve
08:30:39.43599, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800000b3f25f
08:30:39.442989, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800000ddf25f
08:30:39.457858, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000107f25f
08:30:39.470871, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000131f25f

la troisieme salve
08:33:27.435048, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000015bf216
08:33:27.442258, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000185f216
08:33:27.457258, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800001aff216
08:33:27.470455, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800001d9f216

la quatrieme salve
08:36:15.434211, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000203f1cb
08:36:15.441519, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000022df1cb
08:36:15.456584, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000257f1cb
08:36:15.469834, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000281f1cb

ici passage en SBM1
08:38:22.897551, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)
08:38:22.935184, TM_LFR_TC_EXE_SUCCESS, TIME=0x8000032b7671

la cinquieme salve alors que le mode sbm1 est actif mais n'a pas affecté le calcul des CWF_F3 qui arrive 42s apres la derniere (2ab-281 = 2a = 42secondes)
08:39:03.433508, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800002abf186
08:39:03.441489, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800002d5f186
08:39:03.455884, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800002fff186
08:39:03.469272, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000329f186

la sixième salve
08:41:51.432578, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000353f140
08:41:51.439904, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000037df140
08:41:51.454892, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800003a7f140
08:41:51.468305, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800003d1f140

la septieme
08:44:39.43174, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800003fbf0f9
08:44:39.440002, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000425f0f9
08:44:39.454694, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000044ff0f9
08:44:39.468114, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000479f0f9

la huitieme
08:47:27.430787, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800004a3f0b4
08:47:27.438102, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800004cdf0b4
08:47:27.453238, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800004f7f0b4
08:47:27.466666, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000521f0b4

la neuvieme
08:50:15.429841, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000054bf06e
08:50:15.437194, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x80000575f06e
08:50:15.452565, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x8000059ff06e
08:50:15.466231, TM_LFR_SCIENCE_NORMAL_CWF_F3, TIME=0x800005c9f06e

Conclusion:
COMMENT EST CE POSSIBLE??

2 autres tests ont été joués en utilisant juste socexplorer (l'un sans timegen, l'autre avec timegen).
Dans les 2 cas les tests sont concluants et confirment la correction du timing de CWF_F3 et au passage
que le normal mode ne s'interrompt pas quand on passe en SBM1 au moins pour les CWF_F3.

Les fichiers de tests sont stockés dans /home/validation/data/R3/3.0.0.13/TEST6UNITAIRES/new_mode_mode.

Contexte du test
----------------------
FSW 3.0.0.13
VHDL 1.1.89
EM sans Timegen ou avec Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

Je ne m'explique pas le phénomène pour l'instant. J'ai changé la gestion des interruptions pour m'adapter à la nouvelle façon de commuter les modes. C'est peut-être dû à ça. De mon côté, avec MINI-LFR et 0.1.89 + fswf 3.0.0.14, j'ai également des CWF_F3 bien datées.

Le retour des CWF_F3 bien daté a été constaté par plusieurs confs de test (EM2, Mini-lfr, avec et sans timegen).
Il semblerait donc que le pré-diagnostic de JC était erroné, le pb a disparu suite à une modif de la gestion des interruptions dans le FSW.
Je clôture et commenterai le JIRA pour informer le projet.

REOUVERTURE :
Il s'agit bien d'un bug VHDL comme avait dit JC MAIS il se trouve que si l'on commute à une DUE_DATE (pas de commutation immédiate mais à la prochaine seconde) : l'échantillon est correctement daté avec le tps du FPGA.

+
Pour la synchro des SWF, Paul a fait que le ENTER_MODE(0) = immediat est en fait maintenant une commutation à la prochaine seconde donc le bug n'est plus reproductible à priori.
A évaluer et discuter avec Philippe Plasson.
Il faudra donc bien documenter le SUM et discuter avec B. Pontet de tout ça

Accepté par Plasson : voir #584

SUM et RFD : OK