Support #626
closed
Lost TM_LFR_HK in 3.0.0.22
100%
Description
Suite au lancement du test /opt/VALIDATION_R3/test_mode_SBMx_12h.py
On observe la perte d'une TM_LFR_HK au début du test .
2016 2 13 11:48:53:509 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e51d4a2 870c
2016 2 13 11:48:53:513 TM_LFR_TC_EXE_SUCCESS time = 0x 1e51d4a2 8d55
2016 2 13 11:48:54:343 TM_LFR_HK time = 0x 1e51d4a3 628b
2016 2 13 11:48:55:343 TM_LFR_HK time = 0x 1e51d4a6 628b
2016 2 13 11:48:56:343 TM_LFR_HK time = 0x 1e51d4a7 628b
2016 2 13 11:48:57:343 TM_LFR_HK time = 0x 1e51d4a8 628a
Vu également sur la version 3.0.0.20.
3.0.0.20 avec timegen (2016_02_10_17_15_12_packet_log.data)
2016 2 10 17:15:12:504 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e4e2c9e f521
2016 2 10 17:15:12:507 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e f52e
2016 2 10 17:15:12:515 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e f53d
2016 2 10 17:15:12:539 TM_LFR_TC_EXE_SUCCESS time = 0x 1e4e2c9e fc14
2016 2 10 17:15:12:573 TM_LFR_HK time = 0x 1e4e2c9f 6b0
2016 2 10 17:15:13:554 TM_LFR_HK time = 0x 1e4e2ca1 1ee
2016 2 10 17:15:14:554 TM_LFR_HK time = 0x 1e4e2ca2 1ee
2016 2 10 17:15:15:554 TM_LFR_HK time = 0x 1e4e2ca3 1ed
2016 2 10 17:15:16:554 TM_LFR_HK time = 0x 1e4e2ca4 1ed
Si on avait la decommutation des HK, on pourrait voir si le SEQUENCE_CNT du packet est coherent avec une perte de paquet.
J'ai analysé les autres tests et c'est la deuxieme ois que je le vois mais on a peu de tests avec timegen pour comparer.
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 Task #624: Long test with SBM1 and SBM2 FSW 3.0.0.22 added
Updated by Veronique bouzid almost 9 years ago
La perte de HK est encore observée sur un test avec timegen avec le script /opt/VALIDATION_R3/my_test_mode_SBMx.py
qui joue 600s de NORMAL puis 1200s SBM1 + 1200s SBM2+600s de NORMAL.
Les fichiers de test (2016_02_15_12_43_51*) sont sur pc-faust9 dans /home/validation/
[validation@PC-FAUST9 ~]$ vi 2016_02_15_12_43_51_packet_log.data
2016 2 15 12:43:51:675 TM_LFR_TC_EXE_NOT_EXECUTABLE time = 0x 1e548485 d020
2016 2 15 12:43:51:678 TM_LFR_TC_EXE_SUCCESS time = 0x 1e548485 d66b
2016 2 15 12:43:51:844 TM_LFR_HK time = 0x 1e548486 1b3
2016 2 15 12:43:52:845 TM_LFR_HK time = 0x 1e548488 1b3
2016 2 15 12:43:53:845 TM_LFR_HK time = 0x 1e548489 1b3
2016 2 15 12:43:54:845 TM_LFR_HK time = 0x 1e54848a 1b3
2016 2 15 12:43:55:845 TM_LFR_HK time = 0x 1e54848b 1b3
Updated by Veronique bouzid almost 9 years ago
- Related to Bug #629: Lost TM_LFR_HK with timegen added
Updated by Veronique bouzid almost 9 years ago
- Status changed from New to Feedback
On peut utiliser les fichier CSV pour decoder les TM_LFR_HK.
Pour cela, on utilse
soc.lfrControlPlugin.set_storePacketsCSV(1) pour activer le log ou soc.lfrControlPlugin.set_storePacketsCSV(0) pour desactiver.
Ensuite dans le fichier on va pouvoir retrouver les champs qui nous interesse. Il faut raisonner en octet et donc on peut reconstruire les champs facilement.Attention, les 4 octets du Header SPACEWIRE sont présents (32, 2, 0, 0).
Le nom du fichier en sortie sera
Ici un exemple de 2 HKs (3 25)
Le SEQUENCE_CNT est stocké sur l octet 2 et 3 soit 192, 3 pour la premiere et soit C0 03 qui correspond à
11 = STANDELONE PACKET
000000000011 = SEQUENCE_CNT soit 14bits
2016 2 16 09:59:46:570, 32, 2, 0, 0, 12, 196, 192, 3, 0, 129, 16, 3, 25, 0, 30, 85, 175, 144, 98, 155, 1, 13, 81, 3, 0, 0, 22, 1, 1, 89, 1, 8, 0, 1, 50, 1, 10, 0, 10, 0, 10, 0, 5, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 164, 135, 26, 30, 85, 175, 144, 0, 2, 0, 0, 0, 0, 0, 3, 0, 3, 4, 5, 0, 0, 0, 0, 31, 255, 242, 132, 244, 162, 2, 84, 1, 250, 1, 112, 0, 32, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 3, 0, 0, 0, 0, 0
2016 2 16 09:59:47:570, 32, 2, 0, 0, 12, 196, 192, 4, 0, 129, 16,* 3, 25*, 0, 30, 85, 175, 145, 98, 155, 1, 13, 81, 3, 0, 0, 22, 1, 1, 89, 1, 8, 0, 1, 50, 1, 10, 0, 10, 0, 10, 0, 5, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 164, 135, 26, 30, 85, 175, 145, 0, 2, 0, 0, 0, 0, 0, 4, 0, 4, 5, 6, 0, 0, 0, 0, 31, 255, 242, 125, 244, 143, 2, 78, 1, 250, 1, 112, 0, 32, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 4, 0, 0, 0, 0, 0
Updated by bruno katra almost 9 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
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.