Bug #98
closed
TM_LFR_HK: HK_LFR_DPU_SPW_PKT_SENT_CNT périmé
0%
Description
Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.
Les traces obtenues sont:
18:39:41.990076, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=4283, HK_LFR_MODE: SBM1 = 3
18:39:42.336518, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.339775, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.342895, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.345961, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.349016, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.352075, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.355105, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.358179, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.99308, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.996336, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:42.999407, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.002479, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.005525, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.008567, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.011604, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.014636, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x8000082eb855
18:39:43.01665, TM_LFR_HK, TIME=0x8000082ec02a, HK_LFR_DPU_SPW_PKT_SENT_CNT=4299; exp=4300, HK_LFR_MODE: SBM1 = 3 => HK périmé à la reception
18:39:43.648965, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.652146, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.655165, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.658246, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.661389, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.664402, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.667363, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.670313, TM_LFR_SCIENCE_SBM1_CWF_F1
18:39:43.989433, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=4309, HK_LFR_MODE: SBM1 = 3 => Retablissement
Préalablement, on utilise le champ TIME pour reconstituer la chronologie du déroulement des générations de paquets: TM_LFR_HK daté de 18:39:43.01665 est bien postérieur à TM_LFR_SCIENCE_SBM1_CWF_F1 de 18:39:43.014636.
Le pb porte sur HK_LFR_DPU_SPW_PKT_SENT_CNT des TM_LFR_HK.
Les traces montrent que le pb apparait lors qu'il y a coïncidence entre emission de HK et de données SCIENCE:
-l'affectation HK_LFR_DPU_SPW_PKT_SENT_CNT est inférieur à la valeur attendue sur une TM_LFR_HK (cf 18:39:43.01665). La valeur du champ a ainsi été correcte, mais elle est périmée en recoupant avec le champ TIME des TM reçues
-Pour la TM_LFR_HK (de 18:39:43.989433)suivant le défaut , HK_LFR_DPU_SPW_PKT_SENT_CNT est cohérent à la TM_LFR_HK (de 18:39:41.990076) précédant le pb.
nb: pour info, l'écart entre HK_LFR_DPU_SPW_PKT_SENT_CNT attendu et obtenu peut atteindre 7.
A priori, il y aurait deux solutions distinctes:
-Soit, LFR constitue intégralement le TM_LFR_HK pour refléter l'état à un unique instant (stockage de tous les paramètres instantanés puis construction du HK). Quelleque soit ensuite la hierachie des priorités, la date sera cohérente avec les données, même si les données sont dépassées.
-Soit on estime que tous les TM_LFR on le même niveau de priorité. On aura l'état du LFR en live.
Pour info, HK_LFR_DPU_SPW_PKT_SENT_CNT a aussi un pb plus sérieux, tracé par l'issue "TM_LFR_HK: sauts de HK_LFR_DPU_SPW_PKT_SENT_CNT".
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_0061
RPW-SYS-IDB-00067-LES_Issue1_Rev8
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Files
Updated by paul leroy over 10 years ago
Il faut distinguer deux choses:
1) il peut arriver dans les cas où deux TM doivent être émises quasiment simultanément qu'un paquet généré par LFR soit perdu au niveau de la brique. Pour l'instant, je n'ai pas identifié la raison. Ce cas ne se produit pas avec la brique GRESB.
2) lorsque le paquet HK est généré, il est placé dans la FIFO d'émission. Si des paquets sont présents dans la FIFO au moment de la génération du paquet HK, alors ils ne sont pas pris en compte dans le total de paquets émis, qui est géré par le driver spacewire
L'émission continue, plusieurs TM sont émises avant le HK, qui contient une valeur oobsolète par rapport au compteur côté PC
Solution proposée pour 2): le paquet HK peut être placé en tête de FIFO avec une instruction particulière RTEMS. Contrepartie: le paquet HK sera daté avec un temps postérieur aux paquets qui était dans la FIFO d'émission.
Implémenté dans fsw >= 1.0.0.4
Updated by paul leroy over 10 years ago
- Assignee changed from paul leroy to bruno katra
Updated by Veronique bouzid over 9 years ago
- Status changed from Resolved to Closed
- Assignee changed from bruno katra to Veronique bouzid
Le bug est corrigé.
Suite à la validation des soft 2.0.x.x
- Aucune perte de HK n'a été observée sur les tests rejoués
- La verification du champ HK_LFR_DPU_SPW_PKT_SENT_CNT a été remaniée:
- sur la premiere HK du test on extrait le parametre HK_LFR_DPU_SPW_PKT_SENT_CNT
- sur la derniere HK du test on extrait le parametre HK_LFR_DPU_SPW_PKT_SENT_CNT
la différence nous donne le nbre de paquet envoyés durant le test et ensuite, il est facile de compter le nbre de TM_LFR dans le fichier
Detail.txt. Si les 2 chiffres sont égaux, on a perdu aucun paquet.
Le script verif_fields a été adapté pour alculer le nombre de paquets emis durant un test.
Lors de l execution du script verif_fields, le fichier sss_cp_eqs_050.txt commencera par
Nb packets sent is 1643
et ensuite met en evidence les différences HK_LFR_DPU_SPW_PKT_SENT_CNT par TM_HK mais on n en tiendra pas compte.
12:20:49.12136, TM_LFR_HK
HK_LFR_DPU_SPW_PKT_SENT_CNT: res=17; exp=18
--> peut etre faut il enlever ce test mais je prefere le laisser car c'est une indication du flux emis.