Project

General

Profile

Actions
Copy link

Bug #111

closed

Pb de timing dans le traitement de TC_LFR_UPDATE_TIME

Added by Gerald Saule over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Veronique bouzid
Category:
-
Target version:
-
Start date:
02/04/2014
Due date:
% Done:

0%

Estimated time:
revision:
r110

Description

Le changement de temps interne (au LFR) doit se faire sur réception du time code.
Par le code Python, on envoie TC_LFR_UPDATE_TIME, puis le time code 300ms après.

On a les traces:

11:27:26.425912, TM_LFR_HK, ..., TIME=0x000000044139, ..., HK_LFR_MODE: SBM2 = 4, ..., SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=4, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=2, SY_LFR_FPGA_VERSION_N3=255, ..., HK_LFR_UPDATE_TIME_TC_CNT=3, ...
11:27:27.193676, TC_LFR_UPDATE_TIME, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=8658, (PACKET_SEQUENCE_CONTROL=0xe1d2), PACKET_LENGTH=11, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: TIME_MANAGEMENT = 9, SERVICE_SUBTYPE: UPDATE_TIME = 129, SOURCE_ID: MISSION_TIMELINE = 110, CP_RPW_TIME=0x000000000000, CRC = 0x4428
11:27:27.42591, TM_LFR_HK, ..., TIME=0x00000005413a, ..., HK_LFR_UPDATE_TIME_TC_CNT=4, ...
11:27:28.425916, TM_LFR_HK, ..., TIME=0x00000006413c, ...
11:27:29.425921, TM_LFR_HK, ..., TIME=0x00000000ee13, ...

D'après le HK recu à 11:27:27.42591, LFR a reçu le TC_LFR_UPDATE_TIME à TIME=0x00000005413a.
Dans le pire cas (où il faut encore attendre les 300ms pour recevoir le time code, avant la remise à 0 du temps interne), le temps interne ne pourra donc pas dépasser 0x000000058E07 (au format CUC).

Malheureusement, il s'écoule plus d'un seconde avant la prise en compte de la valeur de CP_RPW_TIME.
C'est clairement incompatible avec la cadence possible des TC_LFR_UPDATE_TIME (1Hz).

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.2.255
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.4 (variante sur carte finale)

TEST CASE = SVS-0011
Req = SSS-CP-FS-360

RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2

Files

2014_06_12-15_42_11-Detail.txt (233 KB) 2014_06_12-15_42_11-Detail.txt bruno katra, 13/06/2014 05:23 PM
Actions
Copy link
 #1

Updated by paul leroy over 10 years ago

Relancer le test avec fsw >= 1.0.0.6 et vhdl >= 0.1.10 pour mieux diagnostiquer le problème.

Actions
Copy link
 #2

Updated by paul leroy over 10 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to bruno katra
Actions
Copy link
 #3

Updated by bruno katra over 10 years ago

Test relancé en vhdl 0.1.16 et FSW 1.0.0.8 : Le bug semble corrigé :

- SVS-0011 (traces dans le fichier 2014_06_12-15_42_11-Detail.txt)
    On voit bien l application du temps et le compteur qui s incremente
    TM_LFR_HK TIME=0x800000146f89 HK_LFR_UPDATE_TIME_TC_CNT=0
    TM_LFR_HK TIME=0x000000001cb5 HK_LFR_UPDATE_TIME_TC_CNT=1
    TM_LFR_HK TIME=0x000000011cb6 HK_LFR_UPDATE_TIME_TC_CNT=1
    TM_LFR_HK TIME=0x000000021cb5 HK_LFR_UPDATE_TIME_TC_CNT=1
    TM_LFR_HK TIME=0x000000031cb2 HK_LFR_UPDATE_TIME_TC_CNT=1
    TM_LFR_HK TIME=0x000000042229 HK_LFR_UPDATE_TIME_TC_CNT=1
    TM_LFR_HK TIME=0x0000000522f5 HK_LFR_UPDATE_TIME_TC_CNT=2
    TM_LFR_HK TIME=0x00000000cf8b HK_LFR_UPDATE_TIME_TC_CNT=2 -- TC_LFR_DATE_TIME avec CP_RPW_TIME=0x000000000000 +TimeCode
Avec la trace des données scientifiques (UPDATE_TIME + Timecode à 15:41:51.321852)
    15:41:51.021507, TC_LFR_UPDATE_TIME,CP_RPW_TIME=0x000000000000
    15:41:51.093125, TM_LFR_SCIENCE_BURST_BP1_F0,TIME=0x000000050e33 --Ici le Time code n est pas arrivé
    15:41:51.113247, TM_LFR_SCIENCE_BURST_BP1_F1,TIME=0x0000000517c4
    15:41:52.086791, TM_LFR_SCIENCE_BURST_BP1_F0,*TIME=0x00000000b9de* L update time a ete appliqué
1- Remarque
    La commande TC_LFR_UPDATE_TIME entraine l increment du champ HK_LFR_UPDATE_TIME_TC_CNT de la TM_LFR_HK (sans attendre le timecode) mais pas de mise à jour des
    HK_LFR_LAST_EXE_TC_ID,HK_LFR_LAST_EXE_TC_TYPE,HK_LFR_LAST_EXE_TC_SUBTYPE,HK_LFR_LAST_EXE_TC_TIME.
    C'est normal dixit Paul et effectivement cette commande n est pas acceptée et executée.
Actions
Copy link
 #4

Updated by bruno katra over 10 years ago

Actions
Copy link

Also available in: Atom PDF