Bug #490
closed
[JIRA] (RPWMEB-495) LFR doesn't detect the TIME_TIMECODE_CTR errors
Added by Veronique bouzid over 8 years ago. Updated over 8 years ago.
0%
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
Files
| 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
Updated by Veronique bouzid over 8 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.
Updated by paul leroy over 8 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?
Updated by Veronique bouzid over 8 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
Updated by paul leroy over 8 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.
Updated by paul leroy over 8 years ago
- Assignee changed from paul leroy to Veronique bouzid
corrigé dans fsw >= 3.0.0.9
Updated by Veronique bouzid over 8 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
Updated by paul leroy over 8 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.
Updated by Veronique bouzid over 8 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
Updated by paul leroy over 8 years ago
- Assignee changed from paul leroy to Veronique bouzid
Updated by paul leroy over 8 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é.
Updated by Veronique bouzid over 8 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
Updated by bruno katra over 8 years ago
- Description updated (diff)
- Status changed from Closed to Resolved
Mis en resolved le temps que la SRS soit mise à jour
Updated by Veronique bouzid over 8 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)