Bug #100
closed
Incohérence entre le traitement de TC_LFR_ENTER_MODE et l'affectation de HK_LFR_MODE (TM_LFR_HK)
0%
Description
Cette issue traite du pb de l'issue "Le champ TIME des TM_LFR_HK est parfois incohérent" (http://pc-instru.lpp.polytechnique.fr/redmine/issues/976).
12:04:57.567357, TM_LFR_HK, TIME=0x800012c0c739, HK_LFR_MODE: STANDBY = 0, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15
12:04:58.349075, TC_LFR_ENTER_MODE PACKET_ID=0x1ccc, PACKET_SEQUENCE_CONTROL=0xda07, CP_LFR_ENTER_MODE_TIME=0x000012c20000
12:04:58.366328, TM_LFR_TC_EXE_SUCCESS, TIME=0x800012c193e5, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xda07
12:04:58.549572, TC_LFR_ENTER_MODE, PACKET_ID=0x1ccc, PACKET_SEQUENCE_CONTROL=0xdc9c, CP_LFR_MODE: SBM2 = 4, CP_LFR_ENTER_MODE_TIME=0x000012c30000
12:04:58.568354, TM_LFR_HK, TIME=0x800012c1c745, HK_LFR_MODE: SBM2 = 4
12:04:58.56928, TM_LFR_TC_EXE_SUCCESS, TIME=0x800012c1c7ce, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xdc9c
Lorsque le temps interne vaut 0x12c1c745 (au msb près), le TC_LFR_ENTER_MODE (envoyée a 12:04:58.549572) n'est pas encore acquitté; donc, théoriquement, pas encore executé.
Il y a une incohérence, car:
-soit TIME de TM_LFR_HK est affecté avant que HK_LFR_MODE soit affecté par le mode courant.
-soit le traitement de TC_LFR_ENTER_MODE réalise la transition avant l'élaboration de l'acquittement.
Cette incohérence est résolue après un délai de (0x12c1c7ce−0x12c1c745)÷0x10000=8,9ms.
Nb: la gestion de CP_LFR_ENTER_MODE_TIME n'est actuellement pas implémentée; les transitions sont immédiates.
Ce point est tracé dans l'issue "CP_LFR_ENTER_MODE_TIME de TC_LFR_ENTER_MODE ignoré" (https://hephaistos.lpp.polytechnique.fr/redmine/issues/88).
Contexte:
LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.0.15
Soft: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0072
RPW-SYS-IDB-00067-LES_Issue1_Rev8
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by Gerald Saule over 10 years ago
- revision changed from r1 to r104
Complément de la description ci-dessus (qq s plus tard, lors du déroulement) :
12:05:18.56754, TM_LFR_HK, SEQUENCE_CNT=54, TIME=0x800012d5c745, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=2, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=0, SY_LFR_FPGA_VERSION_N3=15, HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_EXE_TC_CNT=33, HK_LFR_REJ_TC_CNT=5, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=41, HK_LFR_LAST_EXE_TC_TIME=0x800012d5c367, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=41, HK_LFR_LAST_REJ_TC_TIME=0x800012c90ca3, HK_LFR_DPU_SPW_PKT_RCV_CNT=38, HK_LFR_DPU_SPW_PKT_SENT_CNT=123
12:05:19.551354, TC_LFR_ENTER_MODE, PACKET_ID=0x1ccc, PACKET_SEQUENCE_CONTROL=0xe02e, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: ENTER_MODE = 41, CP_LFR_MODE: SBM2 = 4, CP_LFR_ENTER_MODE_TIME=0x000012d70000
12:05:19.567551, TM_LFR_HK, SEQUENCE_CNT=55, TIME=0x800012d6c74a, HK_LFR_MODE: SBM2 = 4, HK_LFR_EXE_TC_CNT=33, HK_LFR_REJ_TC_CNT=5, HK_LFR_LAST_EXE_TC_ID=0x1ccc, HK_LFR_LAST_EXE_TC_TYPE=181, HK_LFR_LAST_EXE_TC_SUBTYPE=41, HK_LFR_LAST_EXE_TC_TIME=0x800012d5c367, HK_LFR_LAST_REJ_TC_ID=0x1ccc, HK_LFR_LAST_REJ_TC_TYPE=181, HK_LFR_LAST_REJ_TC_SUBTYPE=41, HK_LFR_LAST_REJ_TC_TIME=0x800012c90ca3, HK_LFR_DPU_SPW_PKT_RCV_CNT=39, HK_LFR_DPU_SPW_PKT_SENT_CNT=124
12:05:19.570482, TM_LFR_TC_EXE_SUCCESS, TIME=0x800012d6c836, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe02e
Il y a également cett incohérence sur les champs de la TM_LFR_HK daté à 12:05:19.567551: HK_LFR_LAST_EXE_TC_TIME=0x800012d5c367 bien que HK_LFR_LAST_EXE_TC_SUBTYPE=41 !
Updated by paul leroy over 10 years ago
- Status changed from New to Resolved
fsw >= 1.0.0.3
L'origine du comportement est identifiée. Voici le déroulement actuel des actions à réception de TC_LFR_ENTER_MODE
1) si la TC est valide, le mode en cours est arrêté
2) le nouveau mode est configuré au niveau hardware (l'acquisition ne commencera que à la date spécifiée)
3) TM_LFR_TC_EXE_SUCCESS est émise
4) le nouveau mode est indiqué dans les TC (même si l'acquisition bien que configurée n'a pas encore commencé)
Actuellement, le mode démarre dès que possible, la date n'est pas prise en compte, mais l'enchaînement des actions est celui décrit au dessus.
Updated by paul leroy over 10 years ago
- Assignee changed from paul leroy to bruno katra
Updated by Veronique bouzid over 9 years ago
- Status changed from Resolved to Closed
ce n'est pas un bug mais le comportement de LFR.
Les documents SRS ont déja été mis à jour.