Project

General

Profile

Actions

Bug #4015

closed

HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteur HK_LFR_DPU_SPW_RX_TOO_BIG

Added by Veronique bouzid about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
24/01/2023
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Le test SVS-0026 doit vérifier le requirement suivant
All the counters (error counter, packet counter, etc) managed by LFR FSW shall restart at 0 when tehy reached their maximun value.

Le script qui teste le compteur HK_LFR_DPU_SPW_RX_TOO_BIG envoie 257 Tc générant une erreur. Le compteur valide bien le requirement et on voit parfaitement le passage à zero.

Un autre compteur nommé HK_LFR_ME_CNT comptabilise les erreurs de type medium. HK_LFR_DPU_SPW_RX_TOO_BIG fait partie de ce type d erreur et donc on s'attend à la fin du test à obtenir
HK_LFR_ME_CNT=257. Ce n est pas le cas il manque 1.

Ici un extrait des valeurs de ces 2 compteurs (fichir verif_count.txt)
11:47:45.222921 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=0 HK_LFR_DPU_SPW_RX_TOO_BIG=0
11:47:46.242728 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1
11:47:47.222395 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1
11:47:48.223832 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1
11:47:49.222892 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1
11:47:50.223058 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=2 HK_LFR_DPU_SPW_RX_TOO_BIG=2
----

12:04:48.226406 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=255
12:04:49.225973 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0
12:04:50.225914 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0
12:04:51.226438 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0
12:04:52.225955 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0
12:04:53.225879 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:04:54.22646 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:04:55.225976 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:04:56.225969 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:04:57.22624 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:04:58.226003 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:04:59.226005 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:05:00.226468 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1
12:05:01.226032 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1

On voit la parfaite égalité des 2 compteurs excepté après le wrap de HK_LFR_DPU_SPW_RX_TOO_BIG.
Le script joué se nomme /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_rx_too_big_cnt_wrap.py et les fichiers de test sont dans
/home/validation/data/R3.3/3.3.0.11/1.1.91/SVS-0026/TESTS/check_rx_too_big_cnt_wrap

Contexte du test
---------------------
FSW 3.3.0.11
VHDL 1.1.91
EM1 sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+
StarDundee

ATTENTION
Il se peut que ce bug soit applicable également à la gestion du compteur d'erreur HK_LFR_LE_CNT.

Actions #1

Updated by Veronique bouzid about 1 year ago

  • Subject changed from HK_LFR_ME_CNT ne s'incremnet pas lors du passage à zero du compteur HK_LFR_DPU_SPW_RX_TOO_BIG to HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteur HK_LFR_DPU_SPW_RX_TOO_BIG
Actions #3

Updated by Veronique bouzid about 1 year ago

  • Status changed from New to Resolved

Livraison 3.3.0.13 a corrigé le bug.

2 tests ont été joués.
- /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_rx_too_big_cnt_wrap.py
montre que le passage à 0 du champ HK_LFR_DPU_SPW_RX_TOO_BIG et la prise en compte de l'erreur dans HK_LFR_ME_CNT
16:21:56.890956,, HK_LFR_DPU_SPW_RX_TOO_BIG=255, HK_LFR_ME_CNT=255,
16:22:00.891115, HK_LFR_DPU_SPW_RX_TOO_BIG=0, HK_LFR_ME_CNT=256,
16:22:04.891671, HK_LFR_DPU_SPW_RX_TOO_BIG=1, HK_LFR_ME_CNT=257,

les fichiers sont disponibles dans le répertoire /home/validation/data/R3.3/3.3.0.13/1.1.91/SVS-0026/TESTS/check_rx_too_big_cnt_wrap

- /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_me_cnt_wrap.py
montre que le passage à 0 du champ HK_LFR_ME_CNT (65535 puis 0)
20:04:57.275545, HK_LFR_ME_CNT=65533,
20:04:58.275557,HK_LFR_ME_CNT=2,

Entre les 2 TM_LFR_HK, on a envoyé 5 TC trop longues.

Les fichiers sont disponibles dans le répertoire /home/validation/data/R3.3/3.3.0.13/1.1.91/SVS-0026/TESTS/check_me_cnt_wrap.

Reste à valider le passage à 0 du compteur HK_LFR_LE_CNT

Contexte du test
---------------------
FSW 3.3.0.13
VHDL 1.1.91
EM1 sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+
StarDundee

Actions #4

Updated by bruno katra about 1 year ago

  • Status changed from Resolved to Closed
Actions #5

Updated by bruno katra about 1 year ago

  • Status changed from Closed to Resolved
Actions #6

Updated by Veronique bouzid about 1 year ago

  • Status changed from Resolved to Closed

Correction validée en 3.3.0.13.

Le script /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_le_cnt_wrap.py a été joué et le wrap a été observé correctement.

Extrait du fichier 2023_01_26-05_34_26-HKExtract.txt
05:15:10.968296, TM_LFR_HK, TIME=0x000096519ed0, HK_LFR_MODE: STANDBY = 0, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=65534 , HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: TIMECODE_CTR = 26, HK_LFR_LAST_ER_TIME=0x000096510003, HK_LFR_DPU_SPW_TICK_OUT_CNT=95, HK_LFR_DPU_SPW_LAST_TIMC=4, 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=121, HK_LFR_TIMECODE_MISSING=122, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=173, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=94
05:15:11.968273, TM_LFR_HK, TIME=0x000096529bd4, HK_LFR_MODE: STANDBY = 0, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=0 , HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: TIMECODE_CTR = 26, HK_LFR_LAST_ER_TIME=0x000096520003, HK_LFR_DPU_SPW_TICK_OUT_CNT=96, HK_LFR_DPU_SPW_LAST_TIMC=5, 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=121, HK_LFR_TIMECODE_MISSING=122, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=174, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=95

05:15:12.969652, TM_LFR_HK, TIME=0x000096539928, HK_LFR_MODE: STANDBY = 0, HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=2 , HK_LFR_ME_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIME = 42119, HK_LFR_LAST_ER_CODE: TIMECODE_CTR = 26, HK_LFR_LAST_ER_TIME=0x000096530003, HK_LFR_DPU_SPW_TICK_OUT_CNT=97, HK_LFR_DPU_SPW_LAST_TIMC=6, 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=121, HK_LFR_TIMECODE_MISSING=122, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=175, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=96

Les fichiers sont disponibles dans le répertoire /home/validation/data/R3.3/3.3.0.13/1.1.91/SVS-0026/TESTS/check_le_cnt_wrap.

Contexte du test
---------------------
FSW 3.3.0.13
VHDL 1.1.91
EM1 sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+
StarDundee

Actions

Also available in: Atom PDF