¿Perro guardián independiente (IWDG) o perro guardián de ventana (WWDG)?

Todavía estoy buscando encontrar una respuesta a esta pregunta:

¿Por qué si bien las MCU stm32 tienen un perro guardián perfecto (me refiero al perro guardián de ventana (WWDG)), hay un perro guardián simple (perro guardián independiente (IWDG))?

Encontré esta página que dice:

ST Microelectronics tiene una línea de dispositivos Cortex-M3. El M3 se ha vuelto extremadamente popular para los dispositivos integrados de gama baja, y el STM32F de ST es representativo de estas partes (aunque el WDT es un complemento de ST y no necesariamente refleja las implementaciones de otros proveedores). El STM32F tiene dos mecanismos de protección diferentes. Un "perro guardián independiente" es un bonito diseño de vainilla que tiene poco más que facilidad de uso. Pero su Window Watchdog ofrece una protección más robusta. Cuando expira un temporizador de cuenta regresiva, se genera un reinicio, que puede impedirse volviendo a cargar el temporizador. Nada especial allí. Pero si la recarga ocurre demasiado rápido, el sistema también se reiniciará. En este caso, "demasiado rápido" está determinado por un valor que se programa en un registro de control.

Otra característica interesante: puede generar una interrupción justo antes de reiniciar. Escriba un bit de código para enganchar la interrupción y puede tomar algunas medidas para, por ejemplo, poner el sistema en un estado seguro o para capturar datos con fines de depuración. ST sugiere usar el ISR para recargar el perro guardián, es decir, patear al perro para que no se reinicie. No sigas sus consejos. Si el programa falla, los controladores de interrupción pueden continuar funcionando normalmente. Y el uso de un ISR para recargar el WDT invalida toda la razón de un perro guardián de la ventana.

y esto :

La nueva serie de CPU STM32F4 Cortex ™ -M4 de STMicroelectronics tiene dos perros guardianes independientes. Uno corre desde su propio oscilador RC interno. Eso significa que todo tipo de cosas pueden colapsar en la CPU y el WDT seguirá disparando. También hay una "ventana de vigilancia" (WWDT) que requiere que el código le haga cosquillas con frecuencia, pero no con demasiada frecuencia. Esta es una forma muy efectiva de asegurar que el código bloqueado que se escribe aleatoriamente en el mecanismo de protección no cause un cosquilleo WDT, y el WWDT puede generar una interrupción poco antes de que se restablezca el restablecimiento.

ok, echemos un vistazo en el manual de referencia :

El STM32F10xxx tiene dos periféricos de vigilancia integrados que ofrecen una combinación de alto nivel de seguridad, precisión de tiempo y flexibilidad de uso. Ambos periféricos de vigilancia (Independiente y Ventana) sirven para detectar y resolver el mal funcionamiento debido a fallas de software, y para activar el reinicio del sistema o una interrupción (solo vigilancia de ventana) cuando el contador alcanza un valor de tiempo de espera determinado. El watchdog independiente (IWDG) funciona con su propio reloj dedicado de baja velocidad (LSI) y, por lo tanto, permanece activo incluso si falla el reloj principal. El reloj de vigilancia de ventana (WWDG) se escala previamente del reloj APB1 y tiene una ventana de tiempo configurable que se puede programar para detectar un comportamiento anormalmente tardío o temprano de la aplicación. El IWDG es el más adecuado para aplicaciones que requieren que el perro guardián se ejecute como un proceso totalmente independiente fuera de la aplicación principal, pero tienen restricciones de precisión de tiempo más bajas. El WWDG es el más adecuado para aplicaciones que requieren que el watchdog reaccione dentro de una ventana de tiempo precisa.

La ventana de vigilancia se utiliza para detectar la aparición de una falla de software, generalmente generada por interferencia externa o por condiciones lógicas imprevistas, lo que hace que el programa de aplicación abandone su secuencia normal. El circuito de vigilancia genera un reinicio de MCU al expirar un período de tiempo programado, a menos que el programa actualice el contenido de la cuenta regresiva antes de que se borre el bit T6. También se genera un reinicio de MCU si el valor de cuenta regresiva de 7 bits (en el registro de control) se actualiza antes de que la cuenta regresiva haya alcanzado el valor de registro de ventana. Esto implica que el contador debe actualizarse en una ventana limitada.

Como puede ver, ninguno de ellos ha dicho por qué hay dos perros guardianes. si le pregunto cuáles son las diferencias entre los dos perros guardianes, contará todas las características que puede ver en lo anterior y si desea comparar los dos, ¡obviamente el perro guardián de la ventana (WWDG) será el ganador! entonces ¿Por qué hay dos perros guardianes?

Quiero saber cuándo debo usar IWDG y cuándo WWDG.

y hay alguna razón que nos diga ¿Por qué llaman al segundo reloj por este nombre -> "Window watchdog"?

Los temporizadores regulares de vigilancia deben reiniciarse en algún momento antes de que se agote el tiempo. Si tiene un WDT de 100 ms, puede restablecerlo cada 99,9 ms o cada 10us y nunca se agotará.

Los temporizadores de vigilancia de ventana tienen una ventana de tiempo dentro de la cual deben restablecerse. Si lo reinicia demasiado temprano o demasiado tarde (desde el reinicio anterior), el procesador se reiniciará.

El propósito, si no es obvio, es ayudar a garantizar que el código que restablece el WDT sea el código previsto, que funcione de la manera prevista. Algún tipo de condición imprevista que genere reinicios WDT de alta frecuencia no evitará que el sistema se reinicie.

Ejecutar un WDT desde el reloj del sistema podría ser un problema: si el reloj falla y si no hay un circuito de monitor de reloj independiente, pueden suceder cosas malas. El reloj independiente para el WDT significa que si la cosa, por alguna razón, comenzó a funcionar a una velocidad de 1/10, el WDT se restablecería (pero la ventana WDT no).

Usa ambos si puedes.

Como dice la página, reiniciar el WDT con un ISR es generalmente un mal juju (pero puede ser aceptable si el ISR verifica que el reinicio del firmware esté funcionando antes de reiniciar el temporizador).

El texto que pegó en la pregunta le da las respuestas que necesita.

1. Utiliza IWDG cuando necesita un perro guardián simple o cuando necesita un perro guardián completamente independiente: IWDG tiene su propio reloj, WWDG deriva su reloj de uno de los relojes del bus; si falla o su software lo apaga, entonces el perro guardián muere.
2. Utiliza WWDG cuando necesita un watchdog que solo se puede restablecer dentro de un determinado intervalo de tiempo (ventana). Si su software restablece el WWDG demasiado tarde, el WWDG activará un reinicio del procesador. Si su software reinicia el WWDG demasiado TEMPRANO, entonces también provocará un reinicio del procesador.

Se llama un "perro guardián de la ventana" por la sencilla razón de que solo un reinicio del perro guardián durante un período de tiempo específico (ventana de oportunidad) evitará que el perro guardián reinicie su procesador.

Ambos realizan trabajos similares, pero los hacen de manera diferente. Lo que necesita depende de los requisitos que debe cumplir.

Hay otra razón para usar el watchdog de ventana, ya sea en su lugar o además del watchdog independiente. WWDG tiene una interrupción que puedes conectar. Esto significa que, si el código ha entrado en un bucle o fuga, puede establecer un punto de interrupción en el ISR WWDG y trabajar hacia atrás para descubrir qué estaba haciendo el firmware cuando el perro ladró.

No puede hacer esto con IWDG. Como su nombre lo indica, eso es independiente del procesador. En lugar de generar una interrupción, simplemente afirma y desensambla / RESTABLECE, lo que no le da muchas pistas sobre por qué ladró. Sugeriría encarecidamente establecer un WWDG dentro de sus parámetros operativos normales, más un IWDG en un período mucho más largo, quizás 2 * WWDG máximo. Crea una función kick-dog que patee a ambos. De esta manera, el IWDG solo ladra cuando el WWDG también se bloquea, como respaldo final.

Mi opinión sobre esto:

Use ambos al mismo tiempo, porque buscan diferentes condiciones fallidas:

El temporizador de vigilancia independiente (IWDG) debe reiniciarse continuamente antes de que se agote el tiempo de espera. En la práctica, puede agregar el código de reinicio en cualquier lugar donde tenga un estado de programa válido, o una vez en el bucle principal si tiene un bucle principal que se supone que se ejecuta con frecuencia sin demoras importantes. De esta manera, si su llamada para restablecer el temporizador (esto a veces se llama "caricias", "cosquillas o simplemente" restablecer "" el perro guardián ") no se produce a tiempo, significa que su código A) se atascó accidentalmente en algún lugar que no previó --- algún tipo de estado de tipo de bucle infinito imprevisto, o B) se atascó intencionalmente en algún lugar que hizo cumplir a través de unassert()llamada de función con un bucle infinito incrustado al que desea que vaya el código siempre que se no seacumpla alguna condición importante . Entonces, ahora que su condición de afirmación es falsa, su código se atasca intencionalmente en un bucle infinito, y el perro guardián restablece el microcontrolador para devolverlo a un estado válido. Tenga en cuenta también que "el watchdog independiente (IWDG) funciona con su propio reloj dedicado de baja velocidad (LSI) y, por lo tanto, permanece activo incluso si falla el reloj principal" (consulte el Manual de referencia ST RM0008 p493 ).

Sin embargo, me parece que el temporizador Window Watchdog (WWDG) está diseñado para no buscar los casos descritos anteriormente (donde su código, ya sea involuntariamente o intencionalmente [a través de una aserción] se "atasca" en alguna parte), pero más específicamente para el caso donde A) su código NO ejecuta algo que debería . En otras palabras, tiene una falla que hace que su bucle principal u otra subsección de código se ejecute demasiado rápido (o se omita por completo), por lo que restablece el watchdog demasiado pronto, fuera de su ventana, y el mcu se restablece. O B)la otra condición que puede detectar es una configuración fallida del temporizador. Quizás lo esté reiniciando a un intervalo fijo, pero su temporizador utilizado para crear este intervalo cambia sus configuraciones accidentalmente en algún lugar que no debería haberlo hecho, o lo configura mal en primer lugar, entonces el intervalo de tiempo estará apagado, su fijo el restablecimiento del intervalo de tiempo restablecerá el WWDG fuera de su ventana (ya sea demasiado pronto o demasiado tarde), y el mcu se restablecerá para notificarle y / o corregir la condición.

Esta es mi opinión sobre ella. Pensamientos o comentarios son bienvenidos.

El perro guardián "en ventana" es solo un perro guardián regular que protege de alguna manera para prácticas de programación aún peores. Como otros han dicho, usted tiene un "marco de tiempo" generalmente ajustable donde se debe suministrar su "alimentación".

Ninguno de ellos es a prueba de balas si su código puede ingresar en un bucle sostenido automáticamente. P.ej. Si planea "alimentar" en función de las IRQ relacionadas con el temporizador, esto puede ser una práctica extremadamente mala ya que su código puede atascarse en algunas secuencias de correo electrónico, mientras que las interrupciones aún pueden alimentar su WWDT en la secuencia correcta.

En realidad, puede usar interrupciones para alimentar WWDT si puede reducir su prioridad IRQ bajo el código de ejecución normal como lo puede hacer en MIPS (Microchip).

Si su código es vital, crítico, etc., simplemente elimínelos y use WDT externo (preferiblemente preguntas y respuestas basadas en preguntas y respuestas).