Task #655
closed
Mise à jour SRS et SVS / TC > 228 bytes
0%
Description
Mettre à jour la SRS et les tests associés dans la SVS pour expliquer
- comment est traitée la reception d une TC > 228 octets
- remettre à jour les SRS concernant l'acceptance ( orde de d'evaluation des criteres)
Revoir donc SVS-0003 et SVS-0007.
Cette mise à jour est liée à la résolution du Bug #649
Related issues
Updated by Veronique bouzid almost 9 years ago
- Related to Bug #649: CCSDS_TC_PKT_MAX_SIZE wrong: detection of a TC with wrong length added
Updated by Veronique bouzid almost 8 years ago
- Status changed from New to In Progress
Depuis 3.1.0.6 , le comportement implementé par Paul est le suivant
--> Il n y aura jamais de TM_LFR_EXE_CORRUPTED
lors de l envoi d une TC trop long.
Voila la trace mettant en évidence le comportement du soft.
1- La TC sera rejeté par le driver spacewire et donc pas d acquittement, cela se traduit par
13:21:00.500713, /!\No TM_LFR_TC_EXE_* after time-out (4s).
2- La detection d'une TC trop longue est décrite dans la structure spw_stats et ensuite reportée dans les HK. Les champs suivants seront mis à jour
HK_LFR_DPU_SPW_RX_TOO_BIG sera incrementé
HK_LFR_ME_CNT sera incrementé car HK_LFR_DPU_SPW_RX_TOO_BIG est une medium criticity
3- L'erreur de type medium est reportée dans les champs dédiés
HK_LFR_LAST_ER_RID: ME_LFR_DPU_SPW = 42338, HK_LFR_LAST_ER_CODE: RX_TOO_BIG = 9, HK_LFR_LAST_ER_TIME=0x80000012218c
4- Ces champs ne seront pas mis à jour
HK_LFR_LAST_REJ_TC_ID, HK_LFR_LAST_REJ_TC_TYPE, HK_LFR_LAST_REJ_TC_SUBTYPE, HK_LFR_LAST_REJ_TC_TIME
Il faut donc mettre cela dans la SRS et egalement mettre à jour SVS-0003.
Updated by bruno katra over 7 years ago
- Status changed from In Progress to Closed
mis à jour dans SRS 2.1