Project

General

Profile

Feature #588

traitement des champs TIMECODE et TIME dans les paquets HK

Added by paul leroy over 5 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
21/01/2016
Due date:
% Done:

0%

Estimated time:

Description

Expliquer comment sont gérer les champs suivants dans les paquets HK:

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIMECODE
HK_LFR_TIMECODE_ERRONEOUS --> 0
HK_LFR_TIMECODE_MISSING --> 0
HK_LFR_TIMECODE_INVALID --> 0

SOURCE_DATA/PARAMETERS/ERRORS_COUNTERS/TIME
HK_LFR_TIME_TIMECODE_IT --> 0
HK_LFR_TIME_TIMECODE_NOT_SYNCHRO --> 0

History

#1 Updated by paul leroy over 5 years ago

J'ai travaillé sur la gestion des champs suivants:
hk_lfr_timecode_erroneous
hk_lfr_timecode_missing
hk_lfr_timecode_invalid
hk_lfr_time_timecode_it
hk_lfr_time_not_synchro
hk_lfr_time_timecode_ctr

Ils sont normalement gérés comme expliqué dans le document joint, lui même largement copié d'un document de Philippe que je joins également, dans lequel on trouve notamment la sévérité des erreurs.

Les compteurs d'erreurs selon leur sévérité sont construit à chaque génération de paquet HK comme ceci (rev3.0.0.13 de fsw):
//update the low severity error counter
hk_lfr_le_cnt =
housekeeping_packet.hk_lfr_dpu_spw_parity
+ housekeeping_packet.hk_lfr_dpu_spw_disconnect
+ housekeeping_packet.hk_lfr_dpu_spw_escape
+ housekeeping_packet.hk_lfr_dpu_spw_credit
+ housekeeping_packet.hk_lfr_dpu_spw_write_sync
+ housekeeping_packet.hk_lfr_dpu_spw_rx_ahb
+ housekeeping_packet.hk_lfr_dpu_spw_tx_ahb
+ housekeeping_packet.hk_lfr_timecode_erroneous
+ housekeeping_packet.hk_lfr_timecode_missing
+ housekeeping_packet.hk_lfr_timecode_invalid
+ housekeeping_packet.hk_lfr_time_timecode_it
+ housekeeping_packet.hk_lfr_time_not_synchro
+ housekeeping_packet.hk_lfr_time_timecode_ctr;

//update the medium severity error counter
hk_lfr_me_cnt =
housekeeping_packet.hk_lfr_dpu_spw_early_eop
+ housekeeping_packet.hk_lfr_dpu_spw_invalid_addr
+ housekeeping_packet.hk_lfr_dpu_spw_eep
+ housekeeping_packet.hk_lfr_dpu_spw_rx_too_big;
//update the high severity error counter
hk_lfr_he_cnt = 0;

#2 Updated by paul leroy over 5 years ago

  • Assignee changed from paul leroy to Veronique bouzid

#3 Updated by bruno katra over 5 years ago

#4 Updated by Veronique bouzid over 5 years ago

J'ai essayé de résumer ma compréhension de la gestion des time-codes

1- apres la sequence de boot, la tache de supervision des time-codes ( timecode_timer_routine) est lancée. Au bout de 1.2s , la tache va s'executer et traiter l'absence de réception d'' un time-code valide reçu.

--> donc une fois les 1.2s ecoulée on execute timecode_timer_routine
--> qui va detecter time-code MISSING et donc incrementer le compteur
ensuite sortie de la tache et celle-ci n'est pas rearmée
et donc sans arrivée de timecode ni TC_LFR_UPDATE_TIME + time code, on conserve cet etat

Seule l'arrivée d'un time-code permet de réarmer la tache ( timecode_timer_routine)
Est ce correct?

La réponse de Paul:
Oui c'est correct

2- Je n 'ai pas réussi à tester les 2 champs suivants en me basant sur les explications de Paul (#588)
HK_LFR_TIMECODE_ERRONEOUS
HK_LFR_TIMECODE_INVALID
Ils restent donc toujours à 0.

*La réponse de Paul:
Pour tester HK_LFR_TIMECODE_ERRONEOUS
Je n'ai pas réussi à forcer l'exécution du timecode_irq_handler parce que si on force l'IRQ du SpaceWire, ça ne déclenche pas le timecode_irq_handler qui est appelé par le driver SpaceWire à la réception d'un timecode valide. Donc je ne vois pas comment vérifier ça (je pensais qu'on pouvait déclencher artificiellement l'appel à timecode_irq_handler en passant par le contrôleur d'interruption mais l'IRQ SpaceWire est une IRQ générale et c'est le driver qui s'occupe de la traiter).

Pas pu testé HK_LFR_TIMECODE_INVALID*

#5 Updated by Veronique bouzid about 3 years ago

  • Status changed from In Progress to Closed

Also available in: Atom PDF