Project

General

Profile

Bug #87

Perte d'un TM_LFR_HK

Added by Gerald Saule over 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
12/03/2014
Due date:
% Done:

0%

Estimated time:
revision:
r104

Description

Il s'agit d'un phénomène très rare (et donc difficilement reproductible).
Les outils de surveillance automatique (./lfrverif/common/verif_fields.py) permettent d'utiliser "sss-cp-eqs-050" qui met évidence cette issue.

On remarque que la perte d'un HK correspond à peu près avec le mécanismes d'acquittement suite au TC_LFR_ENTER_MODE.

12:09:56.278367, TM_LFR_HK, SEQUENCE_CNT=2017, TIME=0x80000814b026, HK_LFR_MODE: NORMAL = 1, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=17, HK_LFR_REJ_TC_CNT=4, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=41, HK_LFR_LAST_EXE_TC_TIME=0x80000738a2d7, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=13, HK_LFR_LAST_REJ_TC_TIME=0x8000073769a2, HK_LFR_DPU_SPW_PKT_RCV_CNT=21, HK_LFR_DPU_SPW_PKT_SENT_CNT=3117
12:09:56.343328, TM_LFR_SCIENCE_NORMAL_SWF_F2
12:09:56.643295, TM_LFR_SCIENCE_NORMAL_SWF_F2
12:09:56.943474, TM_LFR_SCIENCE_NORMAL_SWF_F2
12:09:57.243305, TM_LFR_SCIENCE_NORMAL_SWF_F2
12:09:57.28402, TC_LFR_ENTER_MODE (CP_LFR_MODE=0)
12:09:57.301865, TM_LFR_TC_EXE_SUCCESS
12:09:58.278362, TM_LFR_HK, SEQUENCE_CNT=2019, TIME=0x80000816b027, HK_LFR_MODE: STANDBY = 0, HK_LFR_UPDATE_INFO_TC_CNT=0, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=18, HK_LFR_REJ_TC_CNT=4, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=41, HK_LFR_LAST_EXE_TC_TIME=0x80000815b671, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=13, HK_LFR_LAST_REJ_TC_TIME=0x8000073769a2, HK_LFR_DPU_SPW_PKT_RCV_CNT=22, HK_LFR_DPU_SPW_PKT_SENT_CNT=3124

Ce pb étant très rare, et sans impact significatif, la 'Priority' est affectée à Low.

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.0.15
Soft: 1.0.0.2 (variante sur carte finale) = r104

Brique Brique Star-Dundee S/N 46120065.

TEST CASE associé(s) = SVS-0029.

RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1


Related issues

Related to Bug #173: perte TM_LFR_HK observé sur plusieurs testsClosed2014-06-17

History

#1 Updated by paul leroy over 7 years ago

  • Status changed from New to Resolved

Ce problème vient de la brique StarDundee et pas de LFR. Normalement, il n'apparaît pas avec la brique GRESB, qui n'est pas capable de générer les timecode.
L'origine du bug n'est pas identifiée actuellement. Il provient peut-être de la façon dont est gérée la brique par le plugin rmapplugin. La prochaine version majeure, basée sur un plugin développé par Alexis corrigera peut-être le bug.

#2 Updated by paul leroy over 7 years ago

  • Status changed from Resolved to In Progress

#3 Updated by paul leroy almost 7 years ago

  • Status changed from In Progress to Closed

Bug annulé, couvert par Bug #149 (Perte de données par la brique StarDundee).

Also available in: Atom PDF