Bug #4012
closed
TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_KCOEFFICIENTS (freq=0)
0%
Description
Dans le test /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0086/load_kcoeff_with_dump_v3-3.py
l'envoi d'un TC_LFR_LOAD_KCOEFFICIENTS avec KCOEFF_FREQ = 0, KCOEFF_1 = 1065353216 à KCOEFF_32 = 1065353216
ne doit pas modifier les KCOEFF contenus dans la TM_LFR_KCOEFFICIENTS_DUMP.
Extrait
TM_LFR_KCOEFFICIENTS_DUMP , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000d233f, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1065353216, SY_LFR_KCOEFF_2=1065353216, SY_LFR_KCOEFF_3=1065353216, SY_LFR_KCOEFF_4=1065353216, SY_LFR_KCOEFF_5=1065353216, SY_LFR_KCOEFF_6=1065353216, SY_LFR_KCOEFF_7=1065353216, SY_LFR_KCOEFF_8=1065353216, SY_LFR_KCOEFF_9=1065353216, SY_LFR_KCOEFF_10=1065353216, SY_LFR_KCOEFF_11=1065353216, SY_LFR_KCOEFF_12=1065353216, SY_LFR_KCOEFF_13=1065353216, SY_LFR_KCOEFF_14=1065353216, SY_LFR_KCOEFF_15=1065353216, SY_LFR_KCOEFF_16=1065353216, SY_LFR_KCOEFF_17=1065353216, SY_LFR_KCOEFF_18=1065353216, SY_LFR_KCOEFF_19=1065353216, SY_LFR_KCOEFF_20=1065353216, SY_LFR_KCOEFF_21=1065353216, SY_LFR_KCOEFF_22=1065353216, SY_LFR_KCOEFF_23=1065353216, SY_LFR_KCOEFF_24=1065353216, SY_LFR_KCOEFF_25=1065353216, SY_LFR_KCOEFF_26=1065353216, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0
On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur modifiée par la TC_LFR_LOAD_KCOEFFICIENTS_alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).
Ici les valeurs de référence récupérées au boot
TM_LFR_KCOEFFICIENTS_DUMP , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1050859893, SY_LFR_KCOEFF_2=1051774863, SY_LFR_KCOEFF_3=3199048410, SY_LFR_KCOEFF_4=3199675526, SY_LFR_KCOEFF_5=1048105208, SY_LFR_KCOEFF_6=1049731468, SY_LFR_KCOEFF_7=3199884855, SY_LFR_KCOEFF_8=3201093691, SY_LFR_KCOEFF_9=1002946415, SY_LFR_KCOEFF_10=993270132, SY_LFR_KCOEFF_11=1052396741, SY_LFR_KCOEFF_12=1051678457, SY_LFR_KCOEFF_13=3193633745, SY_LFR_KCOEFF_14=3195990147, SY_LFR_KCOEFF_15=3202344225, SY_LFR_KCOEFF_16=3204016481, SY_LFR_KCOEFF_17=3191761623, SY_LFR_KCOEFF_18=3194781000, SY_LFR_KCOEFF_19=0, SY_LFR_KCOEFF_20=2147483648, SY_LFR_KCOEFF_21=3164388996, SY_LFR_KCOEFF_22=3169957665, SY_LFR_KCOEFF_23=3164388996, SY_LFR_KCOEFF_24=3169957665, SY_LFR_KCOEFF_25=3156000388, SY_LFR_KCOEFF_26=3161569057, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0
QUESTION
----------------
Est ce un bug ou bien le comportement attendu?
Contexte du test
----------------------
FSW 3.3.0.11 et 3.3.0.12
VHDL 1.1.91
EM2 sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+
StarDundee
Updated by bruno katra almost 2 years ago
On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur par défaut alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).
Tu veux dire les valeurs envoyées plutôt non?
Updated by bruno katra almost 2 years ago
- Status changed from New to Resolved
- Assignee changed from Alexis Jeandet to Veronique bouzid
Salut Véro ! J'ai discuté avec Alexis, c'est bien le comportement attendu contrairement à ce que j'avais compris et t'avais dit du coup...
Alexis confirme : il n'y a qu'un seul tableau en mémoire donc quand tu envoies une TC_LOAD _KCOEFF cela change bien les valeurs en mémoire même sans lancer l'interpolation. D'où la contrainte imposée de le faire uniquement en STDBY pour éviter des calculs dans une phase transitoire.
Je suis désolé je n'avais pas compris cela lors des discussions, c'est le problème des specifs discutées à l'oral dans les couloirs je suppose ;-p
Du coup j'ai dit la même bêtise à Diane, je vais la contacter pour corriger...
Je te laisse clôturer si la réponse te convient.
Updated by Veronique bouzid almost 2 years ago
- Status changed from Resolved to Closed
Le wrap du compteur HK_LFR_LE_CNT est validé par le script /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_le_cnt_wrap.py.
Extrait de
05:15:10.968296 HK_LFR_LE_CNT=65534 HK_LFR_TIMECODE_ERRONEOUS=121 HK_LFR_TIMECODE_MISSING=122 HK_LFR_TIME_TIMECODE_IT=173 HK_LFR_TIME_NOT_SYNCHRO=0 HK_LFR_TIME_TIMECODE_CTR=94
05:15:11.968273 HK_LFR_LE_CNT=0 HK_LFR_TIMECODE_ERRONEOUS=121 HK_LFR_TIMECODE_MISSING=122 HK_LFR_TIME_TIMECODE_IT=174 HK_LFR_TIME_NOT_SYNCHRO=0 HK_LFR_TIME_TIMECODE_CTR=95
05:15:12.969652 HK_LFR_LE_CNT=2 HK_LFR_TIMECODE_ERRONEOUS=121 HK_LFR_TIMECODE_MISSING=122 HK_LFR_TIME_TIMECODE_IT=175 HK_LFR_TIME_NOT_SYNCHRO=0 HK_LFR_TIME_TIMECODE_CTR=96
Les fichiers sont rangés dans le répertoire /home/validation/data/R3.3/3.3.0.13/1.1.91/SVS-0026/TESTS/check_le_cnt_wrap.