Bug #606
closed
Gestion des erreurs: champ HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME
0%
Description
J'ai joué le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0064/spw_failure_standby.py
Ce test consiste à débrancher le connecteur du link1 du spacewire en mode standby.
On va s'interesse à la chnorlogie des detection des erreurs, mixant erreurs de time et spw.
On démarre par une hk où seule l'erreur di time-code miising est décrite: c'est normal. On voit que la détection du time-code est à la fin de la sequence de boot.
14:57:30.929213, TM_LFR_HK, SEQUENCE_CNT=1, TIME=0x8000000348b9, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, H*K_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x800000022f11*, 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
--
dernier hk avant d'enlever le link
14:57:36.527587, TM_LFR_HK, SEQUENCE_CNT=7, TIME=0x8000000948ba, 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=0x800000022f11, 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
reprise apres la remise en service du cable
14:57:43.056605, TM_LFR_HK, SEQUENCE_CNT=9, TIME=0x8000000b48b8, HK_LFR_LE_CNT=3, 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=0x800000022f11, HK_LFR_DPU_SPW_PARITY=1, 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=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
La on voit que l'on a perdu une HK sequence_cnt=8 avec le TIME=0x8000000axxxx.
Ensuite il y a apparition de 2 erreurs HK_LFR_DPU_SPW_PARITY=1, HK_LFR_DPU_SPW_DISCONNECT=1 , detection cherente avec le compteur HK_LFR_LE_CNT=3 mais pas avec la sectio qui décrit la derniere erreur detectée:
HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x800000022f11
Celle-ci correspond à l'abence de time-out détectée apres la sequence de boot.
--> POURQUOI
Les fichiers de test (2016_02_03-14_57_55) se trouvent dans /home/validation/data/R3/3.0.0.16/1.1.89/SVS-0064.
Contexte du test
---------------------
FSW 3.0.0.16
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Updated by paul leroy almost 9 years ago
Oups, je viens de regarder mon code. J'ai écrit une fonction pour détecter une modif dans les stats SpaceWire et changer le champ hk_lfr_last_er, mais j'ai oublié de l'utiliser... Je l'ajoute et je te fais une 3.0.0.18 dans la foulée.
Updated by Veronique bouzid almost 9 years ago
- Status changed from New to Feedback
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
Updated by paul leroy almost 9 years ago
- Assignee changed from paul leroy to Veronique bouzid
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.
Updated by Veronique bouzid almost 9 years ago
L'utilisation du banc de test du LESIA simulateur mk2 pourra nous permet de mieux observer si on perd ou pas une HK car le matériel
n'est pas intrusif.
Updated by Veronique bouzid almost 9 years ago
Une information concernant la gestion des erreurs liées à la lecture de la structure spw_stats
Comme indiqué par Paul, seul le premier champ de la structure (tx_link_err) ne donne pas lieu à une remontée d'erreurs.
En effet les 2 champs suivants
unsigned int rx_rmap_header_crc_err; // NOT IN HK
unsigned int rx_rmap_data_crc_err; // NOT IN HK
ne sont pas comptabilisés car ne correspondent pas à un champ dans les HK mais par contre, ils donnent lieu à une mise à jour
des 3 champs HK_LFR_LAST_ER_RID, HK_LFR_LAST_ER_CODE, HK_LFR_LAST_ER_TIME :
HK_LFR_LAST_ER_RID = RID_LE_LFR_DPU_SPW
HK_LFR_LAST_ER_CODE = CODE_HEADER_CRC
HK_LFR_LAST_ER_TIME = heure de la détection de l'erreur
De plus le compteur d'erreur HK_LFR_LE_CNT sera incrémenté.
Updated by Veronique bouzid over 6 years ago
- Status changed from Feedback to Closed