LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Ben effectivement, j'ai implémenté quelque-chose, mais je ne vois toujours pas bien l'utilité.

La tâche LOAD arme un timer qui doit se déclencher 1.1 seconde après son lancement (timer hardware, pas software, c'est à dire géré par l'IP core gptimer du VHDL, pas par RTEMS). La tâche LOAD s'endort pour1 seconde. A son réveil, elle recharge le timer, qui normalement n'a pas lancé la routine à laquelle il est attaché puisqu'il ne s'est pas écoulé 1.1 secondes. Si le système est bloqué, alors LOAD ne se réveille pas et la routine attachée au timer est lancée.

Question: que soit faire la routine attachée au timer? Autre question: la routine sera-t-elle exécutée si le système est planté au point de ne pas permettre à LOAD de se réveiller?

Voilà, j'ai implémenté ce qu'a implémenté TDS je crois, mais c'est à affiner.

Le 25/01/2016 13:44, Bruno Katra a écrit :

Salut Paul, j'ai vu le changelog de la 3.0.0.13 : concernant le watchdog, lors de la revue QR R3 (la 1ère : celle au CNES) vous aviez parlé avec Philippe de l'implémentation du watchdog et de la façon de le faire car à priori sans intérêt. A la fin de votre discussion où vous aviez évoqué TDS , Philippe avait expliqué comment TDS faisait et dit que l'on pourrait faire pareil (cf. bilan QR ci-dessous). Cette discussion dépassait un peu mon niveau de compréhension mais ça avait l'air de te parler. Ma question donc : un watchdog "à la TDS" c'est quoi ?
Pas la peine de répondre de suite, on pourra causer de ça mercredi.

Merci

A+

Bonjour Bruno,

Le 28 janvier 2016 à 08:56, Bruno Katra <bruno.katra@lpp.polytechnique.fr> a écrit :

Bonjour Philippe, durant la QR R3, Paul et toi avez échangé sur la pertinence et la manière d'implémenter un watchdog au niveau software sur LFR. Il avait été conclu de faire quelque chose "comme TDS". Voici ce que Paul est en train d'implémenter, cela convient-il?

"La tâche LOAD (priorité la plus haute) arme un timer qui doit se déclencher 1.1 seconde après son lancement (timer hardware, pas software, c'est à dire géré par l'IP core gptimer du VHDL, pas par RTEMS). La tâche LOAD s'endort pour 1 seconde. A son réveil, elle recharge le timer, qui normalement n'a pas lancé la routine à laquelle il est attaché puisqu'il ne s'est pas écoulé 1.1 secondes. Si le système est bloqué, alors LOAD ne se réveille pas et la routine attachée au timer est lancée : cette routine fait un exit(0) (comme la TC_LFR_RESET)."

Merci d'avance et bonne journée

Le concept est bon excepté un point : la tâche LOAD doit avoir la priorité la plus basse, sinon le système ne sera pas à même de détecter une boucle sans fin dans une des tâches moins prioritaires. Si, par exemple, la tâche de transmission des TM est bloquée, alors le watchdog ne sera jamais déclenché car toujours réarmé par la tâche LOAD.
En donnant à la tâche LOAD la priorité la plus basse, il faut aussi bien évaluer la période de déclenchement du timer HW et donc évaluer la durée max pendant laquelle une tâche plus prioritaire que la tâche LOAD peut être activée. 1.1 s me paraît trop court : on peut avoir une période d'une dizaine de secondes, ce n'est pas gênant. La période de la tâche LOAD peut elle restée configurée à 1 seconde.

A bientôt,

Philippe

Bruno