LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Bug corrigé en 3.0.0.18.

Le script rejoué est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0064/spw_failure_standby.py
Après l'opération débrancher le cable du link 1 et après 5s remetrre en place le cable voici ce que j'observe dans les fichiers de test

la derniere HK aant l'enlevement du cable

08:22:41.553099, TM_LFR_HK, SEQUENCE_CNT=10, TIME=0x8000000c48da, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x800000022f33, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=0, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=0, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0, HK_LFR_BUFFER_DPU_TC_FIFO=0, HK_LFR_BUFFER_DPU_TM_FIFO=0, HK_LFR_AHB_CORRECTABLE=0, HK_LFR_AHB_UNCORRECTABLE=0, SPARE=0x0

Apres la remise en service du cable:
08:22:49.022261, TM_LFR_HK, SEQUENCE_CNT=12, TIME=0x8000000e48d9, HK_LFR_LE_CNT=2, HK_LFR_ME_CNT=1, HK_LFR_HE_CNT=0, H*K_LFR_LAST_ER_RID: ME_LFR_DPU_SPW = 42338, HK_LFR_LAST_ER_CODE: EARLY_EOP_EEP = 6, HK_LFR_LAST_ER_TIME=0x8000000dc136*, HK_LFR_DPU_SPW_PARITY=0, HK_LFR_DPU_SPW_DISCONNECT=1, HK_LFR_DPU_SPW_ESCAPE=0, HK_LFR_DPU_SPW_CREDIT=0, HK_LFR_DPU_SPW_WRITE_SYNC=0, HK_LFR_DPU_SPW_RX_AHB=0, HK_LFR_DPU_SPW_TX_AHB=0, HK_LFR_DPU_SPW_EARLY_EOP=1, HK_LFR_DPU_SPW_INVALID_ADDR=0, HK_LFR_DPU_SPW_EEP=0, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0, HK_LFR_BUFFER_DPU_TC_FIFO=0, HK_LFR_BUFFER_DPU_TM_FIFO=0, HK_LFR_AHB_CORRECTABLE=0, HK_LFR_AHB_UNCORRECTABLE=0, SPARE=0x0

Observations
1- On a perdu une HK (SEQUENCE_CNT=11 avec un TIME=0x8000000d????
2- 2 erreurs sont apparues en plus
HK_LFR_DPU_SPW_DISCONNECT=1 --> comptabilisée dans HK_LFR_LE_CNT qui est devenu 2
HK_LFR_DPU_SPW_EARLY_EOP=1 --> comptabilisée dans HK_LFR_ME_CNT qui est devenu 1
C'est cette erreur qui est la derniere erreur tracée dans les champs
HK_LFR_LAST_ER_RID: ME_LFR_DPU_SPW = 42338,
HK_LFR_LAST_ER_CODE: EARLY_EOP_EEP = 6,
HK_LFR_LAST_ER_TIME=0x8000000dc136
Et si on regarde le temps de HK_LFR_LAST_ER_TIME, il correspond à la HK que nous avons perdu (0x8000000dc136)

--> Je n'ai pas retrouvé exactement le contexte du test effectué en 3.0.0.16 mais ce que j'observe au niveau de la gestion des erreurs est exacte.
Paul analyse les erreurs du spacewire dans l'ordre de la description des HK
(HK_LFR_DPU_SPW_PARITY, HK_LFR_DPU_SPW_DISCONNECT, HK_LFR_DPU_SPW_ESCAPE, HK_LFR_DPU_SPW_CREDIT, HK_LFR_DPU_SPW_WRITE_SYNC, HK_LFR_DPU_SPW_RX_AHB, HK_LFR_DPU_SPW_TX_AHB, HK_LFR_DPU_SPW_EARLY_EOP, HK_LFR_DPU_SPW_INVALID_ADDR, HK_LFR_DPU_SPW_EEP, HK_LFR_DPU_SPW_RX_TOO_BIG)

et donc le dernier champ en erreur trouvé est celui déclaré dans les champs dédiés.

--> Paul, je te laisse valider le test et repondre à la question
- POURQUOI PERD ON UNE HK?
Cela semble récurrent au vu des tests joués et donc il nous faudra l'identiquer dans notre SRS.

Les fichiers de test (2016_02_04-08_23_01*) sont dans le répertoire /home/validation/data/R3/3.0.0.18/1.1.89/SVS-0064.

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

Pour la perte du HK, je ne suis pas certain qu'il faille incriminer LFR, ça peut venir de la brique. Enlever le câble, c'est un peu violent, pour la brique, pour son driver sur le PC de test, pour LFR. Donc tu peux noter la perte d'un paquet dans le compte-rendu sur le test, mais pas forcément conclure sur l'endroit où celui-ci est perdu.

La perte d'un paquet pourrait venir d'un arrachage du câble pendant l'émission du paquet côté LFR (je ne suis pas sûr que le système essaie de relancer la transmission si elle n'a pas abouti), ou de la perte du paquet entre le moment où il est dans la brique et le moment où il va vers le PC de test.