Feature #588
closed
traitement des champs TIMECODE et TIME dans les paquets HK
0%
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
Files
Updated by paul leroy over 8 years ago
- File TIMECODE and TIME errors handling v1.0 TIMECODE and TIME errors handling v1.0 added
- File RPW-SYS-MEB-###-FMC-000207-LES_Issue3_Rev1_FDIR_Analysis.pdf RPW-SYS-MEB-###-FMC-000207-LES_Issue3_Rev1_FDIR_Analysis.pdf added
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;
Updated by paul leroy over 8 years ago
- Assignee changed from paul leroy to Veronique bouzid
Updated by bruno katra about 8 years ago
- File HK_ERROR_CRITICITY.ods HK_ERROR_CRITICITY.ods added
- File HK_ERROR_CRITICITY.xlsx HK_ERROR_CRITICITY.xlsx added
- Status changed from New to In Progress
Updated by Veronique bouzid about 8 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*
Updated by Veronique bouzid almost 6 years ago
- Status changed from In Progress to Closed