Chien de garde indépendant (IWDG) ou chien de garde de fenêtre (WWDG)?

Je cherche toujours à trouver une réponse à cette question:

Pourquoi, alors que les MCU stm32 ont un chien de garde parfait (je veux dire le chien de garde de fenêtre (WWDG)), il y a un chien de garde simple (chien de garde indépendant (IWDG))?

J'ai trouvé cette page qui a dit:

ST Microelectronics dispose d'une gamme d'appareils Cortex-M3. Le M3 est devenu extrêmement populaire pour les appareils intégrés bas de gamme, et le STM32F de ST est représentatif de ces pièces (bien que le WDT soit un complément ST, et ne reflète pas nécessairement les implémentations d'autres fournisseurs). Le STM32F possède deux mécanismes de protection différents. Un "chien de garde indépendant" est une jolie conception vanille qui n'a que peu d'intérêt en dehors de sa facilité d'utilisation. Mais leur Watchdog Window offre une protection plus robuste. Lorsqu'un compte à rebours expire, une réinitialisation est générée, qui peut être entravée en rechargeant le compte à rebours. Rien de spécial là-bas. Mais si le rechargement se produit trop rapidement, le système se réinitialise également. Dans ce cas, "trop ​​rapidement" est déterminé par une valeur que l'on programme dans un registre de commande.

Autre fonctionnalité intéressante: il peut générer une interruption juste avant la réinitialisation. Écrivez un peu de code pour accrocher l'interruption et vous pouvez prendre des mesures pour, par exemple, mettre le système dans un état sûr ou pour créer des images instantanées à des fins de débogage. ST suggère d'utiliser l'ISR pour recharger le chien de garde - c'est-à-dire, donner un coup de pied au chien afin qu'une réinitialisation ne se produise pas. Ne prenez pas leurs conseils. Si le programme plante, les gestionnaires d'interruption peuvent très bien continuer à fonctionner normalement. Et l'utilisation d'un ISR pour recharger le WDT invalide la raison entière d'un chien de garde de fenêtre.

et ceci :

La nouvelle série de processeurs STM32F4 Cortex ™ -M4 de STMicroelectronics dispose de deux chiens de garde indépendants. L'un s'exécute à partir de son propre oscillateur RC interne. Cela signifie que toutes sortes de choses peuvent s'effondrer dans le processeur et que le WDT se déclenchera toujours. Il existe également un «watchdog de fenêtre» (WWDT) qui nécessite que le code le chatouille fréquemment, mais pas trop souvent. Il s'agit d'un moyen très efficace de garantir que le code bloqué qui écrit de manière aléatoire dans le mécanisme de protection ne provoque pas de chatouillement WDT, et le WWDT peut générer une interruption peu de temps avant la réinitialisation.

ok, jetons un œil dans le manuel de référence :

Le STM32F10xxx possède deux périphériques de surveillance intégrés qui offrent une combinaison de haut niveau de sécurité, de précision de synchronisation et de flexibilité d'utilisation. Les deux périphériques de surveillance (indépendant et fenêtre) servent à détecter et à résoudre les dysfonctionnements dus à une panne logicielle, et à déclencher la réinitialisation du système ou une interruption (fenêtre de surveillance uniquement) lorsque le compteur atteint une valeur de temporisation donnée. Le chien de garde indépendant (IWDG) est cadencé par sa propre horloge dédiée à faible vitesse (LSI) et reste donc actif même si l'horloge principale tombe en panne. L'horloge de surveillance de fenêtre (WWDG) est prédimensionnée à partir de l'horloge APB1 et possède une fenêtre temporelle configurable qui peut être programmée pour détecter un comportement d'application anormalement tardif ou précoce. L'IWDG est le mieux adapté aux applications qui nécessitent que le chien de garde s'exécute en tant que processus totalement indépendant en dehors de l'application principale, mais ont des contraintes de précision de synchronisation plus faibles. Le WWDG est le mieux adapté aux applications qui nécessitent que le chien de garde réagisse dans une fenêtre de synchronisation précise.

Le chien de garde de la fenêtre est utilisé pour détecter la survenance d'un défaut logiciel, généralement généré par des interférences externes ou par des conditions logiques imprévues, qui amène le programme d'application à abandonner sa séquence normale. Le circuit de surveillance génère une réinitialisation MCU à l'expiration d'une période de temps programmée, à moins que le programme ne rafraîchisse le contenu du décompteur avant que le bit T6 ne soit effacé. Une réinitialisation MCU est également générée si la valeur de comptage descendant à 7 bits (dans le registre de contrôle) est actualisée avant que le compteur descendant n'atteigne la valeur de registre de fenêtre. Cela implique que le compteur doit être actualisé dans une fenêtre limitée.

Comme vous pouvez le voir, aucun d'eux n'a dit pourquoi il y a deux chiens de garde. si je demande quelles sont les différences entre les deux chiens de garde, vous compterez toutes les fonctionnalités que vous pouvez voir dans ce qui précède et si vous voulez comparer les deux, évidemment le chien de garde de fenêtre (WWDG) sera le gagnant! alors pourquoi il y a deux chiens de garde?

Je veux savoir quand dois-je utiliser IWDG et quand WWDG?

et y a-t-il une raison qui nous dit Pourquoi appellent-ils la deuxième montre par ce nom -> "Watchdog Window"?

Les minuteries de surveillance régulières doivent être réinitialisées à un moment donné avant leur expiration. Si vous avez un WDT de 100 ms, vous pouvez le réinitialiser toutes les 99,9 ms ou toutes les 10us et il ne s'arrêtera jamais.

Les minuteurs de surveillance de fenêtre ont une fenêtre de temps dans laquelle ils doivent être réinitialisés. Si vous le réinitialisez trop tôt ou trop tard (à partir de la réinitialisation précédente), le processeur se réinitialisera.

Le but, s'il n'est pas évident, est d'aider à garantir que le code de réinitialisation du WDT est le code prévu, fonctionnant de la manière prévue. Une sorte de condition imprévue qui génère des réinitialisations WDT haute fréquence n'empêchera pas la réinitialisation du système.

L'exécution d'un WDT à partir de l'horloge système peut être un peu problématique - si l'horloge échoue et s'il n'y a pas de circuit de surveillance d'horloge indépendant, de mauvaises choses peuvent se produire. L'horloge indépendante du WDT signifie que si la chose commençait pour une raison quelconque à une vitesse de 1/10, le WDT se réinitialiserait (mais pas la fenêtre WDT).

Utilisez les deux si vous le pouvez.

Comme le dit la page, la réinitialisation du WDT avec un ISR est généralement mauvaise juju (mais peut être acceptable si l'ISR vérifie que la réinitialisation du firmware fonctionne avant de réinitialiser la minuterie).

Le texte que vous avez collé dans la question donne les réponses dont vous avez besoin.

1. Vous utilisez IWDG lorsque vous avez besoin d'un simple chien de garde ou lorsque vous avez besoin d'un chien de garde complètement indépendant - IWDG a sa propre horloge, WWDG dérive son horloge de l'une des horloges de bus - s'il échoue ou que votre logiciel l'arrête, le chien de garde meurt.
2. Vous utilisez WWDG lorsque vous avez besoin d'un chien de garde qui ne peut être réinitialisé que dans un certain laps de temps (fenêtre). Si votre logiciel réinitialise le WWDG trop tard, le WWDG déclenchera une réinitialisation du processeur. Si votre logiciel réinitialise le WWDG trop tôt, cela entraînera également une réinitialisation du processeur.

Il est appelé "chien de garde de fenêtre" pour la simple raison que seule une réinitialisation du chien de garde pendant une période de temps spécifiée (fenêtre d'opportunité) empêchera le chien de garde de réinitialiser votre processeur.

Les deux font des travaux similaires, mais ils les font différemment. Ce dont vous avez besoin dépend des exigences que vous devez satisfaire.

Il y a une autre raison d'utiliser le chien de garde de fenêtre, à la place ou ou en plus du chien de garde indépendant. WWDG a une interruption que vous pouvez accrocher. Cela signifie que, si le code est entré dans une boucle ou une fugue, vous pouvez définir un point d'arrêt dans le WWDG ISR et revenir en arrière pour savoir ce que le micrologiciel faisait lorsque le chien aboyait.

Vous ne pouvez pas faire cela avec IWDG. Comme son nom l'indique, cela est indépendant du processeur. Plutôt que de déclencher une interruption, il affirme et supprime simplement / RESET - ce qui ne vous donne pas beaucoup d'indices pour expliquer pourquoi il a aboyé. Je suggère fortement de définir un WWDG dans vos paramètres de fonctionnement normaux, plus un IWDG à une période beaucoup plus longue, peut-être 2 * WWDG maximum. Créez une fonction kick-dog qui donne un coup de pied aux deux. De cette façon, l'IWDG aboie uniquement lorsque le WWDG se verrouille également, en tant que sauvegarde finale.

Ma vision:

Utilisez les deux en même temps, car ils recherchent des conditions d'échec différentes:

La minuterie du chien de garde indépendant (IWDG) doit être réinitialisée en permanence avant son expiration . En pratique, vous pouvez simplement ajouter le code de réinitialisation partout où vous avez un état de programme valide, ou une fois dans la boucle principale si vous avez une boucle principale qui est censée s'exécuter fréquemment sans retards majeurs. De cette façon, si votre appel pour réinitialiser la minuterie (cela est parfois appelé "caresser", "chatouiller, ou simplement" réinitialiser "" le chien de garde ") ne se produit pas à temps, cela signifie que votre code soit A) accidentellement coincé quelque part que vous n'aviez pas prévu --- une sorte d'état imprévu de type boucle infinie, ou B) coincé intentionnellement quelque part que vous avez appliqué via unassert()appel de fonction avec une boucle infinie incorporée à laquelle vous voulez que le code aille chaque fois qu'une condition importante n'est pas vraie. Donc, maintenant que votre condition d'assertion est fausse, votre code se bloque intentionnellement dans une boucle infinie et le chien de garde réinitialise le microcontrôleur pour le remettre dans un état valide. Notez également que "le chien de garde indépendant (IWDG) est cadencé par sa propre horloge dédiée à faible vitesse (LSI) et reste donc actif même en cas de défaillance de l'horloge principale" (voir le manuel de référence ST RM0008 p493 ).

Il me semble cependant que le minuteur Window Watchdog (WWDG) est conçu pour ne pas rechercher les cas décrits ci-dessus (où votre code soit involontairement ou intentionnellement [via une assertion] se "bloque" quelque part), mais plus spécifiquement pour le cas où A) votre code n'exécute PAS quelque chose qu'il devrait . En d'autres termes, il a une erreur qui provoque l'exécution trop rapide de sa boucle principale ou d'une autre sous-section de code (ou qu'il soit entièrement ignoré), de sorte que vous réinitialisez le chien de garde trop tôt, en dehors de sa fenêtre, et le MCU est réinitialisé. Ou, B)l'autre condition qu'il peut détecter est une configuration de minuterie qui a échoué. Peut-être que vous le réinitialisez à un intervalle fixe, mais votre minuterie utilisée pour créer cet intervalle obtient ses configurations modifiées accidentellement quelque part qu'il ne devrait pas avoir, ou vous le configurez mal en premier lieu, puis l'intervalle de temps sera désactivé, votre fixe la réinitialisation de l'intervalle de temps réinitialisera le WWDG en dehors de sa fenêtre (trop tôt ou trop tard), et le mcu sera réinitialisé pour vous avertir et / ou corriger la condition.

Voici ma façon de voir les choses. Les réflexions ou commentaires sont les bienvenus.

le chien de garde "fenêtré" est juste un chien de garde régulier qui protège certains pour des pratiques de programmation encore pires. Comme d'autres l'ont dit, vous avez un «délai» généralement réglable à l'endroit où votre «flux» doit être fourni.

Aucun d'entre eux n'est à l'épreuve des balles si votre code peut entrer dans une boucle maintenue automatiquement. Par exemple. Si vous prévoyez de "nourrir" en fonction des IRQ liés à la minuterie, cela peut être une très mauvaise pratique car votre code peut rester bloqué dans certains do / while dans le thread de messagerie, tandis que les interruptions peuvent toujours alimenter votre WWDT dans le bon ordre.

En fait, vous pouvez utiliser des interruptions pour alimenter WWDT si vous pouvez réduire votre priorité IRQ sous le code d' exécution normal comme vous pouvez le faire sur MIPS (Microchip).

Si votre code est vital, critique, etc., il suffit de les supprimer tous et d'utiliser un WDT externe (basé sur les questions et réponses de préférence).