Project

General

Profile

Bug #657

Updated by Veronique bouzid about 8 years ago

 
 En Analysant le passage à zero des compteurs d'erreurs suivants (HK_LFR_TIMECODE_MISSING et HK_LFR_TIME_NOT_SYNCHRO, j observe bien le passage de 255 vers 0 
 pour les compteurs d'erreur codés sur 8 bits mais l'effet non attendu est que les compteurs HK_LFR_xE_CNT qui eux sont codés sur 16 bits ne sont plus bons car 
 ils representent la somme des erreurs liées à une criticité    et donc le fait qu'un compteur passe à 0 diminue la valeur du ce compteur    HK_LFR_xE_CNT 
 Voici un extrait du fichier Detail.txt 

 15:54:46.122923, TM_LFR_HK, TIME=0x000000ff81da, HK_LFR_UPDATE_TIME_TC_CNT=255, *HK_LFR_LE_CNT=509,* HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: NOT_SYNCHRO = 25, HK_LFR_LAST_ER_TIME=0x8000013bd189, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, 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=255*, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, *HK_LFR_TIME_NOT_SYNCHRO=254,* HK_LFR_TIME_TIMECODE_CTR=0 

 15:54:47.122944, TM_LFR_HK, TIME=0x0000010081da, HK_LFR_UPDATE_TIME_TC_CNT=255, *HK_LFR_LE_CNT=254,* HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x000001003270, HK_LFR_DPU_SPW_TICK_OUT_CNT=255, HK_LFR_DPU_SPW_LAST_TIMC=63, 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=0,* HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, *HK_LFR_TIME_NOT_SYNCHRO=254*, HK_LFR_TIME_TIMECODE_CTR=0 

 Ceci est donc valable pour n'importe quel compteur codé sur 8 bits et utilisé dans une somme. 

 Les fichiers (2016_02_25-16_00_04-) sont dans /home/validation/data/R3/3.0.0.22/1.1.89/SVS-0078/not_synchro. 
 Probleme remonté en lancant verif_fields sur le fichier Detail.txt. 
 Le fichier sss_cp_eqs_050.txt met en evidence les observations et permet de valider les passages à zero des compteurs : 

 15:54:47.122944, TM_LFR_HK 
 HK_LFR_LE_CNT: res=254; exp>=509 HK_LFR_TIMECODE_MISSING: res=0; exp>=255 

 15:55:49.123074, TM_LFR_HK 
 HK_LFR_DPU_SPW_TICK_OUT_CNT: res=0; exp>=255 HK_LFR_DPU_SPW_LAST_TIMC: res=0; exp>=63 

 15:56:50.123381, TM_LFR_HK 
 HK_LFR_LE_CNT: res=1; exp>=256 HK_LFR_TIME_NOT_SYNCHRO: res=0; exp>=255 


 Le script utilisé se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0078/update_time_not synchro_cnt_wrap.py. 

 Contexte du test 
 --------------------- 
 FSW 3.0.0.22 LFR_FSW_PATH = /opt/LFR/LFR-FSW/3.0.0.22/fsw 
 VHDL 1.1.89 
 EM sans Timegen 
 SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481 
 StarDundee 



Back