LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Voici des précisions:
dans mon exemple, la commande TM_LFR_TC_EXE_CORRUPTED est envoyée par la fonction tc_check_length qui verifie la coherence entre le subtype de la TC et la long attendue (definie dans ICD).

DONC JE CONFIRME QUE LA DETECTION D'UNE TC AVEC UNE LG > 228 octets (216 en application ) ne fonctionne pas.

Je viens d'écrire un script qui va envoyer une TC avec une longueur > 255 pour valider le code écrit par Paul et voir la réaction du soft.
il se nomme /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0003/send_bad_tc1.py

J envoie une TC correspondant à packet_lg = 263 et avec le type = 181 et subtype = 63.
Cette TC est correctement formattée excepté sa taille.
Attention cette valeur correspond au nombre d'octets -1 de PACKET DATA FIELD .
Cela correspond donc à une TC de longueur 264+6=270 octets
6 pour PACKET HEADER

Voici la réponse du soft
le fichier 2016_03_09-12_41_06-Detail.txt montre

12:41:01.418377, /!\TC too long with lg is 274 --> On a 4 octets en plus liés au Spacewire

12:41:01.451066, TM_LFR_TC_EXE_CORRUPTED, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=25, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000622c8, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xec3f, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=93, PA_RPW_PKT_LEN_RCV_VALUE=263, PA_RPW_PKT_DATFIELDSIZE_CNT=246, PA_RPW_RCV_CRC=0x3f, PA_RPW_COMPUTED_CRC=0x84c9

12:41:01.463547, TM_LFR_TC_EXE_CORRUPTED, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=25, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, /!\DESTINATION_ID: 128, TIME=0x8000000625b4, PA_RPW_TELECOMMAND_PKT_ID=0x3f80, PA_RPW_PKT_SEQ_CONTROL=0x0, PA_RPW_TC_FAILURE_CODE: CORRUPTED = 42005, PA_RPW_TC_SERVICE=0, PA_RPW_TC_SUBTYPE=63, PA_RPW_PKT_LEN_RCV_VALUE=16256, PA_RPW_PKT_DATFIELDSIZE_CNT=7, PA_RPW_RCV_CRC=0xf26d, PA_RPW_COMPUTED_CRC=0xb0fa

On a donc un probleme car on recoit 2 TM_LFR_EXE_CORRUPTED.

Ce comportement est donc à corriger.

Un bug intattendu. Le driver SpaceWire permet de configurer la taille maximale d'un paquet reçu par le hardware (actuellement 252 octets, c'est définit dans le fichier fsw_config.c des sources), je n'avais jamais essayé d'envoyer un paquet trop grand.

// GRSPW0 resources
struct drvmgr_key grlib_grspw_0n1_res[] = {
    {"txBdCnt", KEY_TYPE_INT, {(unsigned int)50}}, // 7 SWF_F0, 7 SWF_F1, 7 SWF_F2, 7 CWF_F3, 7 CWF_F1 ou 7 CWF_F2
        {"rxBdCnt", KEY_TYPE_INT, {(unsigned int)10}},
        {"txDataSize", KEY_TYPE_INT, {(unsigned int)4096}},
        {"txHdrSize", KEY_TYPE_INT, {(unsigned int)34}},
        {"rxPktSize", KEY_TYPE_INT, {(unsigned int)248+4}},
        KEY_EMPTY
};

J'ai l'impression que le paquet est découpé en deux parties. Ce qui expliquerait pourquoi il y a deux paquets d'erreur, et que le deuxième comporte des valeurs farfelues pour les type, subtype etc..

Concrètement, si tu envoies une TC d'une taille immense, elle est découpée en tronçons qui valent la longueur configurée dans le driver, et non mon paramètre CCSDS_TC_PKT_MAX_SIZE.

Je propose donc de configurer le driver SpaceWire pour qu'il soit capable de gérer des TC de taille 228. Si tu envoies une TC de taille supérieure, elle est découpée en tronçons (comme dans des transmissions TCP), et tu obtiens plusieurs paquets d'erreur (autant que de tronçons). Et donc de mettre:

{"rxPktSize", KEY_TYPE_INT, {(unsigned int)228+4}},

où 4 est là pour les octets ajoutés par le protocole (le hardware enlève le premier octet il me semble, celui de l'adresse).

En conséquence, je peux aussi supprimer le test

if ( packetLength >= CCSDS_TC_PKT_MAX_SIZE ) {
            status = WRONG_LEN_PKT;
        }

qui n'a pas de sens puisque le driver ne transmettra que des tronçons de 228

Tu utilisais quelle version du logiciel de vol? J'ai regardé dans mes sources, normalement la modification devrait être effective à partir de la version 3.1.0.1 (changement visible à la révision 290 (135d1e42c4e1) du dépôt DVE_PLE). Tu ne vois aucune différence de comportement?

Pour la signification des champs, l'ICD dit:

PA_RPW_PKT_LEN_RCV_VALUE TC - - - Value of the field Packet Length of the corrupted TC.
Il s'agit donc de l'information reçue dans la TC.

PA_RPW_PKT_DATFIELDSIZE_CNT TC - - - Number of bytes of the Packet Data Field from corrupted TC minus 1.
Il s'agit donc de la taille du data field effectivement constatée, moins 1.

Je lis dans le document rtems-gaisler-drivers-1.2.11.0.pdf que j'ai dans le package rtems fourni par Gaisler:

The driver can be configured using driver resources as described in the driver manager chapter. Below is a description of configurable driver parameters. The driver parameters is unique per GRSPW device. The parameters are all optional, the parameters only overrides the default values.

Puis dans le tableau qui suit dans le document:

rxPktSize INT Maximum packet size of received packets.

Dans les sources grspw.c, on peut voir une valeur par défaut. Je ne comprends pas d'où peut venir le 270.

#define SPACEWIRE_RXPCK_SIZE 1024

Je confirme que les paramètres modifiés que j'utilise pour configurer le driver SpaceWire ne sont pas pris en compte. Ce sont les paramètres par défaut qui s'appliquent.

Dans grspw.c:

/* initialize the code with some resonable values,
     * actual initialization is done later using ioctl(fd)
     * on the opened device */
    pDev->config.rxmaxlen = SPACEWIRE_RXPCK_SIZE;
    pDev->txdbufsize = SPACEWIRE_TXD_SIZE;
    pDev->txhbufsize = SPACEWIRE_TXH_SIZE;
    pDev->rxbufsize = SPACEWIRE_RXPCK_SIZE;
    pDev->txbufcnt = SPACEWIRE_TXBUFS_NR;
    pDev->rxbufcnt = SPACEWIRE_RXBUFS_NR;

Et aussi:

#define SPACEWIRE_INIT_TIMEOUT 10
#define SPACEWIRE_BDTABLE_SIZE 0x400
#define SPACEWIRE_TXD_SIZE 1024
#define SPACEWIRE_TXH_SIZE 64
#define SPACEWIRE_RXPCK_SIZE 1024
#define SPACEWIRE_TXBUFS_NR 64
#define SPACEWIRE_RXBUFS_NR 128

Pour ne pas changer trop la configuration, je propose de vivre avec les valeurs par défaut, qui sont utilisées actuellement, mais de corriger le traitement des télécommandes trop grandes.

J'ai refait des tests avec le driver de la version 1.2.20 de RCC et en fixant les paramètres de tailles avec l'appel à

status = ioctl(fd, SPACEWIRE_IOCTRL_SET_PACKETSIZE, packetsize); // set rxsize, txdsize and txhsize

avec

spw_ioctl_packetsize packetsize;

    packetsize.rxsize = 228;
    packetsize.txdsize = 4096;
    packetsize.txhsize = 34;

Le comportement observé est le suivant. Pour une TC > 228 bytes, le driver ne remonte pas l'arrivée des données (pas de paquet d'erreur généré, la TC est complètement ignorée). Pour des TC <= 228, le paquet est traité et le message d'erreur attendu est envoyé.

Modifications effectives dans fsw >= 3.1.0.5.