Project

General

Profile

Bug #490

[JIRA] (RPWMEB-495) LFR doesn't detect the TIME_TIMECODE_CTR errors

Added by Veronique bouzid about 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Urgent
Category:
SRS
Target version:
-
Start date:
09/09/2015
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

METTRE A JOUR SRS
-------------------
Voici un point JIRA datant du 09/Sep/15 9:31 AM

See the test log AT_2015-09-07_16-18-51

From 16:44:58, the time message (S9) sent by the DAS to the analyzers each second is no more synchronized with the time-code value. THR and TDS detect the problem and increment properly the HK_xxx_TIME_TIMECODE_CTR counter.
This is not the case of LFR for which the HK_LFR_TIME_TIMECODE_CTR remains stuck to 0.

Moreover, the failure is no traced in the ANOMALY_STATISTICS parameters.

See for example the packet TM_LFR_HK dated from 16:45:04

AT_2015-09-07_16-18-51.xlsx (565 KB) AT_2015-09-07_16-18-51.xlsx Veronique bouzid, 09/09/2015 01:45 PM

Related issues

Related to Bug #491: Liste des champs contenus dans TM_LFR_HK non renseignés.Closed2015-09-09

Related to Support #545: Send TIMECODE without TC_LFR_UPDATE_TIME after SYNCHRONISATIONClosed2015-10-20

History

#1 Updated by Veronique bouzid about 6 years ago

je mets le fichier de log

Je confirme que la section PARAMETERS/ANOMALY_STATISTICS n'est jamais mise à jour ainsi que la section PARAMETERS/ERROR_COUNTERS/TIMECODE et PARAMETERS/ERROR_COUNTERS/TIME.

D'autres champs des HK ne sont renseignés --> ouvrir un point REDMINE regroupant les champs de TM_LFR_HK non renseignés.

#2 Updated by paul leroy about 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to Veronique bouzid

Peux-tu me donner le numéro de l'exigence de la SSS à considérer? Je n'avais pas vu qu'il fallait qu'LFR fasse cela. THR et TDS le faisant, j'aimerais voir où pêcher l'information avant de faire la correction. C4est répercuté dans la SRS?

#3 Updated by Veronique bouzid about 6 years ago

  • Assignee changed from Veronique bouzid to paul leroy

Hello,
Quand on s'est vu vendredi matin, je t ai parlé de ce point de gestion des RID. Je n'ai rien trouvé , pas de SSS mais dans l ICD, les valeurs sont définies. That's it.

Il faut peut etre contacter les autres acteurs de THR et TDS.

Véronique

#4 Updated by paul leroy about 6 years ago

L'exigence SSS associée est la SSS-CP-FS-370.

Les 6 bits de poids faible du timecode SpaceWire doivent être égaux aux 6 bits de poids faible du CP_RPW_TIME reçu dans le paquet TC_LFR_UPDATE_TIME émis 300ms avant le timecode.

#5 Updated by paul leroy about 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid

corrigé dans fsw >= 3.0.0.9

#6 Updated by Veronique bouzid about 6 years ago

  • Assignee changed from Veronique bouzid to paul leroy

merci d'expliquer le mécanisme que tu as implémenté pour que je puisse renseigner la SRS

#7 Updated by paul leroy about 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid

La réception d'un timecode valide lève une interruption. Dans l'ISR correspondante, je vérifie sur les 6 bits du timecode sont égaux aux 6 bits de la valeur du registre coarse_time_load (qui contient la dernière valeur reçue par TC_LFR_UPDATE_TIME). Si les valeurs sont différentes, j'incrémente le compteur time_timecode_ctr des paquets HK.

#8 Updated by Veronique bouzid about 6 years ago

  • Assignee changed from Veronique bouzid to paul leroy
  • Priority changed from Normal to Urgent

Je ne sais pas dire si le bug est correctement corrigé en 3.0.0.10.

Voici le scénario joué
Envoi de TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1b45fd010000 + 300ms un timecode = 01
Envoi de TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1b45fd020000 + 300ms un timecode = 02
Envoi de TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1b45fd020000 + 3ààms un timecode = 03

Le résultat donne
09:28:03.329801, TM_LFR_HK, TIME=0x8000000b31b9, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:03.516653, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1b45fd010000
09:28:04.329893, TM_LFR_HK, TIME=0x1b45fd0182d4, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:05.329842, TM_LFR_HK, TIME=0x1b45fd0282d4, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:06.329827, TM_LFR_HK, TIME=0x1b45fd0382d4, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:07.329801, TM_LFR_HK, TIME=0x1b45fd0482d4, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:08.329836, TM_LFR_HK, TIME=0x1b45fd0582d4, HK_LFR_DPU_SPW_TICK_OUT_CNT=1, HK_LFR_DPU_SPW_LAST_TIMC=1, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:08.859356, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1b45fd020000
09:28:09.329796, T*M_LFR_HK, TIME=0x1b45fd022b23*, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:10.329828, TM_LFR_HK, TIME=0x1b45fd032b23, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:11.329893, TM_LFR_HK, TIME=0x1b45fd042b23, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:12.329844, TM_LFR_HK, TIME=0x1b45fd052b23, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:13.329874, TM_LFR_HK, TIME=0x1b45fd062b23, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:14.210765, TC_LFR_UPDATE_TIME, CP_RPW_TIME=0x1b45fd020000
09:28:14.329856, TM_LFR_HK, TIME=0x1b45fd072b23, HK_LFR_DPU_SPW_TICK_OUT_CNT=2, HK_LFR_DPU_SPW_LAST_TIMC=2, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0
09:28:15.329868, TM_LFR_HK, TIME=0x1b45fd02d12*1, *HK_LFR_DPU_SPW_TICK_OUT_CNT=3, HK_LFR_DPU_SPW_LAST_TIMC=*3, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, *HK_LFR_TIME_TIMECODE_CTR=1
09:28:16.329894, TM_LFR_HK, TIME=0x1b45fd03d121, HK_LFR_DPU_SPW_TICK_OUT_CNT=3, HK_LFR_DPU_SPW_LAST_TIMC=3, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=0, HK_LFR_TIMECODE_INVALID=0, , HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=1

1- Le champ HK_LFR_TIME_TIMECODE_CTR=1 est bien positionné mais on voit également que le temps demandé (0x1b45fd02) dans la TC_LFR_UPDATE_TIME a été pris en compte car le temps de la TM_LFR_HK a été positionné au temps denandé (0x1b45fd02).

--> EST CE NORMAL????

2- Tu n'as pas répondu à la phrase
Moreover, the failure is no traced in the ANOMALY_STATISTICS parameters.

les fichiers (2015_10_07-09_28_24*) sont rangés dans le répertoire /home/validation/data/R3/3.0.0.10/TESTS-UNITAIRES/JIRA-49

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

#9 Updated by paul leroy about 6 years ago

  • Assignee changed from paul leroy to Veronique bouzid

#10 Updated by paul leroy about 6 years ago

Le comportement lors d'une erreur sur la différence du timecode et des bits de poids faibles d'un TC_LFR_UPDATE_TIME est-il spécifié? Si ce n'est pas spécifié, tu peux préciser dans la SRS que lorsque LFR reçoit un timecode erroné au sens TC_LFR_UPDATE_TIME, mais correct car incrémenté de 1 par rapport à son prédécesseur, le temps contenu dans TC_LFR_UPDATE_TIME est utilisé.

#11 Updated by Veronique bouzid about 6 years ago

  • Category set to SRS
  • Status changed from Feedback to Closed

La réponse de Paul:
Pour moi, la séquence est respectée: tu as reçu un TC_LFR_UPDATE_TIME et un timecode valide. Je n'ai pas vu de détail sur ce que l'on doit faire si TC_LFR_UPDATE_TIME n'est pas cohérent avec le timecode.

Je clos.

Mettre à jour la SRS

#12 Updated by bruno katra about 6 years ago

  • Description updated (diff)
  • Status changed from Closed to Resolved

Mis en resolved le temps que la SRS soit mise à jour

#13 Updated by Veronique bouzid about 6 years ago

  • Status changed from Resolved to Closed

Mise à jour de la SRS version 1.9, requirement REQ-LFR-SRS-5219 (SSS-CP-FS-370)

Also available in: Atom PDF