Project

General

Profile

Support #626

Lost TM_LFR_HK in 3.0.0.22

Added by Veronique bouzid over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Start date:
13/02/2016
Due date:
% Done:

100%

Estimated time:
revision:
r0

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

ANALYSE-HK (1.94 KB) ANALYSE-HK Veronique bouzid, 13/02/2016 04:46 PM

Related issues

Related to Task #624: Long test with SBM1 and SBM2 FSW 3.0.0.22Closed2016-02-12

Related to Bug #629: Lost TM_LFR_HK with timegenClosed2016-02-16

History

#1 Updated by Veronique bouzid over 4 years ago

  • Related to Task #624: Long test with SBM1 and SBM2 FSW 3.0.0.22 added

#2 Updated by Veronique bouzid over 4 years ago

  • Description updated (diff)

#3 Updated by Veronique bouzid over 4 years ago

  • Description updated (diff)

#4 Updated by Veronique bouzid over 4 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

#5 Updated by Veronique bouzid over 4 years ago

  • Related to Bug #629: Lost TM_LFR_HK with timegen added

#6 Updated by Veronique bouzid over 4 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

#7 Updated by bruno katra over 4 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.

Also available in: Atom PDF