LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

J'ai été mis au courant il y a 10 jours de ce problème : issue JIRA https://jira-lesia.obspm.fr/browse/RPWMEB-599
De mémoire, après un TC_LFR_RESET( exit(0) ), P.Plasson avait dit qu'il détectait le fait que le soft était arrêté et qu'ils étaient capables de redémarrer LFR. Apparemment cela ne fonctionnait pas sur l'EM2.
Voici le contenu résumé de l'issue JIRA :

During the preparation of the RPW Short Functional Test v3.1 on MEB EM2, a problem during LFR reset has been observed.

La carte LFR semble ne plus répondre à la fin de l'étape de configuration du processeur (première étape du boot RMAP) suite à la TC_LFR_RESET.

Les testlogs sont également disponibles en attaché dans "Failure on LFR booting process - Testlogs.7z".

L'historique de la conversation es disponible en attaché sur le fichier "Failure on LFR booting process.msg". Voici le dernière échange de cette conversation:

    Le DAS génère bien un événement TX_TIMEOUT juste avant de générer les erreurs MISSING RMAP réponses : cela signifie que le DAS a bien initié la transmission du paquet SpaceWire RMAP vers LFR, mais que cette transmission ne se termine pas car LFR ne répond plus.
    Quand le DAS détecte le timeout, il force un reset de l'interface SpaceWire : la connexion devrait se refaire automatiquement, mais ce n'est pas le cas : LFR ne répond plus et le DAS génère cette fois-ci une erreur de timeout sur la connexion SpaceWire.

Conclusion : je ne vois pas de dysfonctionnement avéré du DAS mais plutôt une carte LFR qui ne semble plus répondre à la fin de l'étape de configuration du processeur (première étape du boot RMAP). Je pense qu'il va falloir essayer de reproduire le problème avec la MEB PFM.