Bug #629
closed
Lost TM_LFR_HK with timegen
0%
Description
Je viens d'ecrire un petit test (/opt/VALIDATION_R3/my_test_mode.py qui ne dure que 6 secondes pour verifier si je peux reproduire la perte de HK. C'est le cas.
1- Lancement du script Timegen + set_time
2 on envoie une TC enter-mode en standby
3- on envoie une TC entre-mode en normal
4 on attend 5s (utilisation de la fct soc.wait(5)
les logs montrent la perte de JK
2016 2 16 09:59:50:426 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e55af94 3774
2016 2 16 09:59:50:429 TM_LFR_TC_EXE_SUCCESS time = 0x 1e55af94 3dbd
2016 2 16 09:59:50:570 TM_LFR_HK time = 0x 1e55af94 629a
2016 2 16 09:59:51:571 TM_LFR_HK time = 0x 1e55af95 629a
2016 2 16 09:59:52:571 TM_LFR_HK time = 0x 1e55af97 629a
2016 2 16 09:59:53:570 TM_LFR_HK time = 0x 1e55af98 6299
2016 2 16 09:59:54:570 TM_LFR_HK time = 0x 1e55af99 6299
2016 2 16 09:59:55:232 TM_LFR_SCIENCE_NORMAL_BP1_F0 time = 0x 1e55af95 1
2016 2 16 09:59:55:256 TM_LFR_SCIENCE_NORMAL_BP1_F1 time = 0x 1e55af95 1
2016 2 16 09:59:55:268 TM_LFR_SCIENCE_NORMAL_BP1_F2 time = 0x 1e55af95 e6
J'ai enregistré le format CSW qui me permet de verifier le sequence_cnt des HK
2016 2 16 09:59:50:426, 32, 2, 0, 0, 12, 193, 192, 0, 0, 19, 16, 1, 8, 254, 30, 85, 175, 148, 55, 116, 28, 204, 0, 0, 164, 16, 181, 41, 13, 81
2016 2 16 09:59:50:429, 32, 2, 0, 0, 12, 193, 192, 1, 0, 13, 16, 1, 7, 254, 30, 85, 175, 148, 61, 189, 28, 204, 0, 0
--> 3 25 indique TM_LFR_HK et le SEQUENCE_CNT est en gras et correct
2016 2 16 09:59:50:570, 32, 2, 0, 0, 12, 196, 192, 7, 0, 129, 16, 3, 25, 0, 30, 85, 175, 148, 98, 154, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89, ....
2016 2 16 09:59:51:571, 32, 2, 0, 0, 12, 196, 192, 8, 0, 129, 16, 3, 25, 0, 30, 85, 175, 149, 98, 154, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89, ....
2016 2 16 09:59:52:571, 32, 2, 0, 0, 12, 196, 192, 9, 0, 129, 16, 3, 25, 0, 30, 85, 175, 151, 98, 154, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89,
2016 2 16 09:59:53:570, 32, 2, 0, 0, 12, 196, 192, 10, 0, 129, 16, 3, 25, 0, 30, 85, 175, 152, 98, 153, 1, 29, 81, 3, 0, 0, 22, 1, 1, 89,
--> Il n'y a pas de perte de HK si on se fit au SEQUENCE_CNT mais plutot une erreur de datation.
Les fichiers (2016_02_16_09_59_50*) sont dans /home/validation.
Contexte du test
---------------------
FSW 3.0.0.22
VHDL 1.1.89
EM AVEC Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Files
Related issues
Updated by Veronique bouzid almost 9 years ago
- Related to Support #626: Lost TM_LFR_HK in 3.0.0.22 added
Updated by Veronique bouzid almost 9 years ago
Bug observé egalement suite au long test lancé l(#624)
Début du fichier 2016_02_16_17_26_11_packet_log.data rangé dans le répertoire /home/validation/data/R3/3.0.0.22/TESTCHARGE/sbm1+sbm
016 2 16 17:26:11:959 TM_LFR_HK time = 0x 1e561832 1ca
2016 2 16 17:26:12:959 TM_LFR_HK time =* 0x 1e561834 1c9*
2016 2 16 17:26:13:959 TM_LFR_HK time = 0x 1e561835 1c9
2016 2 16 17:26:14:959 TM_LFR_HK time = 0x 1e561836 1c8
2016 2 16 17:26:15:959 TM_LFR_HK time = 0x 1e561837 1c8
Le fichier csv n'a pas été généré donc il faut verifier le SEQUENCE_CNT avec l'éditeur hexa.
Voila c'est fait
1eer HK ( 0x 1e561832 1ca) en gras le sequence_cnt (Attention, j affiche en hexa donc il faut inverser les octets pour lire
0000000 c40c *6b*c0 8100 0310 0019 561e 3218 ca01
0000020 0d01 0351 0000 0116 5901 0d01 0100 0132
0000040 000a 000a 000a 0005 0000 006c 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000100 0000 0000 0000 0000 00d8 0000 a400 1a87
0000120 561e 3218 0200 0000 0000 6c00 6b00 2d6d
0000140 0000 0000 ff1f 83f2 a1f4 4e02 fb01 6e01
0000160 2000 0000 0000 0000 0000 0000 0000 0000
0000200 006c 006c 0000 0000
2eme Hk (0x 1e561834 1c9) on voit bien que le sequenceccnt est incrémenté de 1 alors que le cham TIME est incrementé de 2s
c40c *6c*c0 8100 0310
0000220 0019 561e 3418 c901 0d01 0351 0000 0116
0000240 5901 0d01 0100 0132 000a 000a 000a 0005
0000260 0000 006d 0000 0000 0000 0000 0000 0000
0000300 0000 0000 0000 0000 0000 0000 0000 0000
0000320 00da 0000 a400 1a87 561e 3418 0200 0000
0000340 0000 6d00 6c00 2e6e 0000 0000 ff1f 79f2
0000360 96f4 4b02 fc01 7101 2000 0000 0000 0000
0000400 0000 0000 0000 0000 006d 006d 0000 0000
Updated by Veronique bouzid almost 9 years ago
- File test_mode_SBMx_12h.py test_mode_SBMx_12h.py added
- File test_mode_SBMx_12h.py test_mode_SBMx_12h.py added
- Status changed from New to Closed
Bug provoqué par le banc de test.
1- On a utilisé en premier le script /opt/VALIDATION_R3/LFRControlPlugin_startAll+setTime.py
qui crée l'instance soc puis mise à l'heure de LFR avec le temps du pc (setTimeGenval( soc ))
2 - La sequence suivante de notre test a été commentée
- create a SocFunction object to access SocEplorer
#soc = socfunctions.SocFunctions( LFRControlPlugin0, SpwPlugin0 )
- send the local time to the time generator
#settimegen.setTimeGen( soc )
On a refait des tests et le problème a disparu.