Bug #4015
closed
HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteur HK_LFR_DPU_SPW_RX_TOO_BIG
0%
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.
Updated by Veronique bouzid almost 2 years 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
Updated by Alexis Jeandet almost 2 years ago
En effet je pense avoir trouvé l'erreur:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blob/R3%2B%2B/src/fsw_misc.c#L837
Vs:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blob/R3.3/src/fsw_housekeeping.c#L161
Où MAX_OF retourne 255 ce qui fait le bug au passage à 0...
Updated by Veronique bouzid almost 2 years 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
Updated by bruno katra almost 2 years ago
- Status changed from Resolved to Closed
Updated by bruno katra almost 2 years ago
- Status changed from Closed to Resolved
Updated by Veronique bouzid almost 2 years 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