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

Navega tus respuestas
12

Todavía estoy buscando una respuesta para esta pregunta:

¿Por qué mientras que las MCU stm32 tienen un perro guardián perfecto (me refiero a un perro guardián de la ventana (WWDG)), hay un perro guardián simple (un perro guardián independiente (IWDG))?

Encontré esta página que ha dicho:

  

ST Microelectronics tiene una línea de dispositivos Cortex-M3. El M3 se ha vuelto extremadamente popular para 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 no tiene otra opción que la facilidad de uso. Pero su Window Watchdog ofrece una protección más robusta. Cuando un temporizador de cuenta regresiva expira, se genera un reinicio, que puede impedirse al volver 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 programa de valor uno en un registro de control.

     

Otra característica interesante: puede generar una interrupción justo antes   reajuste Escribe un poco de código para enganchar la interrupción y puedes tomar   alguna acción para, por ejemplo, poner el sistema en un estado seguro o para   datos de instantáneas para fines de depuración. ST sugiere usar el ISR para   vuelva a cargar el perro guardián, es decir, saque al perro para que no se reinicie   ocurrir. No sigas su consejo. Si el programa bloquea la interrupción.   los manejadores pueden continuar funcionando normalmente. Y usando un ISR   volver a cargar el WDT invalida todo el motivo de un watchdog de ventana.

y this :

  

La nueva serie STMicroelectronics de CPUs STM32F4 Cortex ™ -M4 tiene dos   perros guardianes independientes Uno corre desde su propio oscilador interno RC.   Eso significa que todo tipo de cosas pueden colapsar en la CPU y en el   WDT todavía disparará. También hay un "watchdog de ventana" (WWDT) que   requiere el código para hacerle cosquillas con frecuencia, pero no con demasiada frecuencia. Esto es   una forma muy efectiva de asegurar el código estrellado que escribe aleatoriamente en   El mecanismo de protección no causa un cosquilleo WDT, y el WWDT puede   genere una interrupción poco antes de que se confirme el reinicio.

ok, veamos 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   utilizar. Ambos periféricos de vigilancia (Independiente y Ventana) sirven para   detectar y resolver fallos de funcionamiento debidos a fallos del software, y   reiniciar el sistema o una interrupción (solo watchdog de ventana) cuando el   contador alcanza un valor de tiempo de espera determinado. El perro guardián independiente (IWDG)   es cronometrado por su propio reloj dedicado de baja velocidad (LSI) y por lo tanto permanece   activa incluso si el reloj principal falla. El reloj de vigilancia de la ventana (WWDG)   se precalifica desde el reloj APB1 y tiene una ventana de tiempo configurable   que se puede programar para detectar aplicaciones anormalmente tardías o tempranas   comportamiento. El IWDG se adapta mejor a las aplicaciones que requieren la   perro guardián para ejecutar como un proceso totalmente independiente fuera de la principal   aplicación, pero tienen menores restricciones de precisión de tiempo. El WWDG es   más adecuado para aplicaciones que requieren que el perro guardián reaccione dentro de   una ventana de tiempo precisa.

     

El watchdog de la ventana se usa para detectar la aparición de un software   falla, generalmente generada por interferencia externa o imprevista   Condiciones lógicas, lo que hace que el programa de aplicación abandone.   Su secuencia normal. El circuito de vigilancia genera un reinicio de MCU en   expiración de un período de tiempo programado, a menos que el programa actualice   El contenido del contador descendente antes de que se borre el bit T6. Un MCU   el restablecimiento también se genera si el valor del contador descendente de 7 bits (en el control   registro) se actualiza antes de que el contador haya llegado a la ventana   valor de registro. Esto implica que el contador debe actualizarse en un   ventana limitada.

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

Quiero saber cuándo, ¿cuándo debo usar IWDG y cuándo WWDG?

y hay alguna razón que nos diga por qué llaman a la segunda alerta con este nombre - > "Window watchdog"?

    
pregunta Roh

5 respuestas

20

Los temporizadores de vigilancia regulares deben restablecerse 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 10 unidades y nunca se agotará.

Los temporizadores de vigilancia de la ventana tienen una ventana de tiempo dentro de la cual se deben restablecer. Si lo reinicia demasiado pronto o demasiado tarde (a partir del reinicio anterior), el procesador se reiniciará.

El propósito, si no es obvio, es ayudar a garantizar que el código reiniciado del WDT sea el código intencionado, operando de la manera prevista. Algún tipo de condición imprevista que genere reinicios de 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 ocurrir cosas malas. El reloj independiente para el WDT significa que si la cosa, por algún motivo, comenzara a funcionar a una velocidad de 1/10, el WDT se reiniciará (pero la ventana WDT no).

Usa ambos si puedes.

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

    
respondido por el Spehro Pefhany
6

El texto que pegaste en la pregunta da las respuestas que necesitas.

  1. Usted usa IWDG cuando necesita un simple watchdog o cuando necesita un watchdog 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 watchdog muere.
  2. Utiliza WWDG cuando necesita un watchdog que solo se puede restablecer dentro de un cierto intervalo de tiempo (ventana). Si su software restablece el WWDG demasiado tarde, entonces el WWDG disparará un reinicio del procesador. Si su software restablece el WWDG demasiado pronto, también causará un reinicio del procesador.

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

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

    
respondido por el JRE
5

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 puede enganchar. Esto significa que, si el código se ha metido en un bucle o una fuga, puede establecer un punto de interrupción en el ISR de WWDG, y trabajar hacia atrás para averiguar qué estaba haciendo el firmware cuando el perro ladró.

No puedes hacer esto con IWDG. Como su nombre lo indica, eso es independiente del procesador. En lugar de provocar una interrupción, simplemente afirma y desactiva / REAJUSTE, lo que no le da muchas pistas sobre por qué ladró. Recomiendo 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 * máximo WWDG. Crea una función de kick-dog que patea ambos. De esta manera, el IWDG solo ladra cuando el WWDG se bloquea también, como una copia de seguridad final.

    
respondido por el Jon Green
1

Mi opinión sobre él:

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

El temporizador Perro guardián independiente (IWDG) debe reiniciarse continuamente antes de que se agote el tiempo. En la práctica, solo puede agregar el código de reinicio en cualquier lugar en el que tenga un estado de programa válido, o una vez en el ciclo principal si tiene un ciclo principal que se supone que debe ejecutarse con frecuencia sin demoras importantes. De esta manera, si su llamada para restablecer el temporizador (a veces se llama "acariciar", "hacer cosquillas o simplemente" reiniciar "" el perro guardián ") no ocurre a tiempo, significa que su código A) accidentalmente se quedó atascado en algún lugar que no previó --- algún tipo de estado de bucle infinito imprevisto, o B) intencionalmente quedó bloqueado en algún lugar donde se aplicó mediante una llamada a la función assert() con un bucle infinito incrustado al que desea que vaya el código siempre que alguna condición importante sea no verdadera. 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 reinicia el microcontrolador para devolverlo a un estado válido. Tenga en cuenta también que "el perro guardián independiente (IWDG) está sincronizado por su propio reloj dedicado de baja velocidad (LSI) y por lo tanto permanece activo incluso si falla el reloj principal "(consulte ST RM0008 Reference Manual p493 ).

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

Este es mi punto de vista. Los pensamientos o comentarios son bienvenidos.

    
respondido por el Gabriel Staples
0

El watchdog "de ventana" es solo un watchdog regular que protege de alguna manera incluso para peores prácticas de programación. Como han dicho otros, usted tiene un "marco de tiempo" generalmente ajustable donde debería suministrarse su "fuente".

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 base a las IRQ relacionadas con el temporizador, esto puede ser una práctica extremadamente mala, ya que su código puede atascarse en algunos procesos mientras está en el hilo del correo, mientras que las interrupciones pueden alimentar su WWDT en la secuencia correcta.

En realidad, puede usar interrupciones para alimentar WWDT si puede reducir su prioridad de IRQ bajo la ejecución normal como puede hacerlo en MIPS (Microchip).

Si su código es de soporte vital, crítico, etc., simplemente elimínelos todos y use WDT externo (preferiblemente Q & A basado).

    
respondido por el orfruit

Lea otras preguntas en las etiquetas

¿Qué sucede después de que un diodo Zener se descompone? 50 hertz de onda sinusoidal en el osciloscopio cuando lo toco [duplicar]