Activity
From 13/03/2014 to 11/04/2014
10/04/2014
-
04:18 PM Bug #57: TC_LFR_LOAD_NORMAL_PAR renvoie TM_LFR_TC_EXE_NOT_IMPLEMENTED si SY_LFR_N_SWF_L <> default value
- Reproduit dans le contexte ci dessous.
+Contexte:+
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
C... -
- TEST CASE = SVS-0034; SVS-0070/LfrEnterModeTime
-
- CP_LFR_ENTER_MODE_TIME n'est actuellement pas prise en compte correctement:
> 10:23:31.251123, TM_LFR_HK, TIME=0x0...
09/04/2014
-
- Le champ SEQUENCE_CNT des TM correspond au nombre de TM pour chaque couple (PACKET_ID,DESTINATION_ID).
Il y a un pb ...
03/04/2014
-
- La contre-manip décrite ci-dessous montre que le pb se reproduit de façon aléatoire.
L'initialisation du traitement ... -
- LFR émet TM_LFR_TC_EXE_ERROR sans justification.
Au démarrage, la commande d'une transition vers STANDBY est rejetée...
02/04/2014
-
- Les HK de début d'execution sont en
> 11:26:59.425762, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET ... -
- Cette issue est proche de l'issue Bug #111 "Pb de timing dans le traitement de TC_LFR_UPDATE_TIME" (https://hephaisto...
-
- Le changement de temps interne (au LFR) doit se faire sur réception du time code.
Par le code Python, on envoie TC_L...
01/04/2014
-
09:47 AM Bug #77 (Resolved): Reset HW met à 0 le bit MSB du temps interne (qui représente la synchronisation avec un "time code")
- fsw >= 1.0.0.5
vhdl >= 0.1.9
La fonction de gestion du temps est normalement complètement opérationnelle. Au démarr... -
- fsw >= 1.0.0.5
vhdl >= 0.1.9
Au démarrage, le temps est réinitialisé à 0x80000000. LFR attend une synchro valide ... -
-
- Un test avec fsw = 1.0.0.5 en mode NORMAL avec les paramètres par défaut déclenche une émission des paquets TM_LFR_SC...
-
- La valeur 65528 est le multiple de 8 le plus proche de 65535.
La nécessité d'avoir des multiples de 8 comme périod... -
- fsw >= 1.0.0.5
Les champs TIME et ACQUISITION_TIME sont maintenant identiques dans les paquets SWF et CWF..
31/03/2014
-
04:59 PM Bug #108 (Closed): Champs TIME et ACQUISITION_TIME différents dans les TM_LFR_SCIENCE_*
- Dans les TM science, les 2 champs TIME ont des valeurs différentes alors que ceux-ci devraient avoir la même valeur A...
-
- fsw >= 1.0.0.5
Le traitement est maintenant indépendant du champ PACKET_LENGTH lu dans le paquet.
Le CRC est calcul... -
- fsw >= 1.0.0.5
bug identifié et corrigé -
- fsw >= 1.0.0.5
La fonction de commutation de mode à une date fixée est implémentée conformément à la SSS:
=> un mod... -
- fsw >= 1.0.0.5
bug identifié et corrigé.
28/03/2014
-
- Pour déterminer la longueur de la TC, le LFR FSW utilise le contenu du champ PACKET_LENGTH.
C'est une implémentation... -
- TM_LFR_HK, SY_LFR_FPGA_VERSION_N3=255 est une coquille.
On attend SY_LFR_FPGA_VERSION_N3=7.
Contexte:
LPPMON Ver... -
- Le pb n'est pas corrigé. Extraits de traces (toute TM_LFR_SCIENCE_x confondus) :
* > nom=300s, mean=300.00390625s, é... -
- Le bug ne devrait pas se produire avec fsw >= 1.0.0.3.
-
- Bug non reproduit avec fsw = 1.0.0.4 et vhdl = 0.1.7
Vérification en lançant le mode BURST et en regardant les logs ... -
- Voici la façon dont est vérifiée la cohérence des TC:
=> on scrute la TC dans l'ordre en commençant par le premier b... -
- Ce problème vient de la brique StarDundee et pas de LFR. Normalement, il n'apparaît pas avec la brique GRESB, qui n'e...
-
- fsw >= 1.0.0.4
pour la mesure du temps de boot, un paquet HK est émis à la fin du boot avec tous les octets à 0xff h... -
-
- Il faut distinguer deux choses:
1) il peut arriver dans les cas où deux TM doivent être émises quasiment simultanéme... -
- avec fsw <= 1.0.0.3 et peut-être quelques versions ultérieures, voici comment démarrent les modes:
=> réception de l...
27/03/2014
-
- A chaque salve de (huit) TM_LFR_SCIENCE_BURST_CWF_F2, PA_LFR_ACQUISITION_TIME est incrémenté de 0xA8000 (ie 10.5s). C...
25/03/2014
-
- fsw >= 1.0.0.3
L'origine du comportement est identifiée. Voici le déroulement actuel des actions à réception de TC_L... -
- Plantage non reproduit avec fsw = 1.0.0.3 en développement.
Test relancé (dépot VALIDATION, changeset 6, b518198185a...
20/03/2014
-
- Une variante de ce phénomène est observable sur TM_LFR_SCIENCE_NORMAL_SWF_F1 (avec PA_LFR_PKT_NR=1 à chaque fois).
O... -
- Le même genre de cas se reproduit avec le TM_LFR_SCIENCE_NORMAL_SWF_Fx:
> 16:08:30.359944, TC_LFR_LOAD_NORMAL_PAR, S... -
- Complément de la description ci-dessus (qq s plus tard, lors du déroulement) :
> 12:05:18.56754, TM_LFR_HK, SEQUENCE... -
- Cette issue traite du pb de l'issue "Le champ TIME des TM_LFR_HK est parfois incohérent" (http://pc-instru.lpp.polyte...
19/03/2014
-
- Les transitions de mode étant faites à la réception du time code (pour des raisons de synchronisation de l'ensemble d...
-
- Le rejet lorsque CP_LFR_ENTER_MODE_TIME<'temps interne' (SSS-CP-EQS-322) n'est également pas réalisé.
> 16:08:02.2... -
- Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.
Les traces obtenue... -
- Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.
Les traces obtenue...
17/03/2014
-
- (Cette issue reprend Bug #698 "La durée du boot du LFR FSW semble trop longue" de pc-instru).
Le pluggin dsu3plugin ... -
- Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_SBM1_SWF_F2, est vu une fois erroné, de façon très exeptionnelle (...
-
- Le priority est passé en NORMAL, car la non affectation est en contradiction avec la SSS "The nominal case is to tran...
-
- SY_LFR_N_CWF_LONG_F3 du TC_LFR_LOAD_NORMAL_PAR packet n'a pas de valeur par défaut dans RPW-SYS-MEB-LFR-ICD-00097_Iss...
14/03/2014
-
- Il y a 25 composantes dans une matrice spectrale, pas 30, modifier la fonction BP1_set en conséquence.
-
- La fonction BP1_set génère une erreur de type "0x07 = Memory access to un-aligned address" à l'exécution dès que i = ...
13/03/2014
-
- A partir du passage en mode BURST, la première TM_LFR_SCIENCE_BURST_CWF_F2 est envoyée 13s plus tard.
C'est inatendu...
Also available in: Atom