Project

General

Profile

Actions

Feature #598

closed

Implémentation watchdog

Added by bruno katra almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
SRS
Target version:
-
Start date:
28/01/2016
Due date:
% Done:

100%

Estimated time:

Description

Faire un WD "à la tds" suite à QR R3

Actions #1

Updated by bruno katra almost 9 years ago

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+

Actions #2

Updated by bruno katra almost 9 years ago

Bonjour Bruno,

Le 28 janvier 2016 à 08:56, Bruno Katra <> 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
Actions #3

Updated by bruno katra almost 9 years ago

  • Status changed from New to In Progress
  • Assignee set to paul leroy
  • % Done changed from 0 to 50
Actions #4

Updated by paul leroy almost 9 years ago

  • Assignee changed from paul leroy to bruno katra

J'ai modifié le fonctionnement:

Le timer matériel affecté au watchdog a une durée de 10 secondes. Il est réarmé toutes les secondes par la tâche LOAD qui a une priorité très basse.

En cas de perte de lien prolongée, la tâche LINK (tâche de haute priorité qui s'occupe d'attendre que le lien revienne) s'occupe de le recharger. La tâche LINK se rendort et repasse la main à la tâche LOAD si le lien revient.

Actions #5

Updated by bruno katra almost 9 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

fait dans SRS 2.0

Actions

Also available in: Atom PDF