La importancia del Watchdog

[planeta9999]

 

Estaba cuestionándome sobre la importancia del uso del Watchdog, en desarrollos profesionales. La verdad, nunca le he tenido cariño al Watchdog, para mi era un incordio o algo irrelevante.

Recientemente estuve intercambiando mensajes en los foros de NXP sobre el tema del bootloader encriptado con uTasker (que va de fábula), y para tratar de resolver algunos problemas, su autor me sugirió desactivar temporalmente el Watchdog, y aunque al final los tiros no iban por ahí, me hizo un comentario que me hizo pensar.

¿ Que pensais sobre la importancia del Watchdog, es tan imprescindible como me han sugerido para usos profesionales ?

 
" P.S. The watchdog concept is generally the most important part of any product design. Arduino always disables it as far as I known but this is probably due to the fact that the Arduino libraries are intended for maker's projects where simplicity has priority over reliability. For professional work Arduino is a starting point but needs further development in order to achieve adequate quality.
 
This blog entry may highlight some important reasons to be very careful with Arduino:
http://embedded.fm/blog/2017/8/12/dont-use-arduino-for-professional-work "

[manwenwe]

Yo no lo suelo usar. El wdt te da un diagnóstico de que algo has programado mal o no has tenido en cuenta algún escenario pero no soluciona el problema. Si se te atasca el código por lo que sea puedes resetear o volver a un estado anterior pero eso no evitará que el bug vuelva a darse. Yo soy más de encontrarme con las sorpresas y luego solucionarlas jejeje. Aq no pongo en duda q sea útil: si no se hubiese dejado de poner en los micros y ahí lleva décadas...

Gran artículo!

[KILLERJC]

Yo si lo uso, pero lo uso en el caso del codigo "final" y no un codigo que todavia esta en desarrollo. Porque intento evitar todo el tema de lidiar con el WDT hasta ese ultimo momento y Como pocas veces termino usando un delay muy grande, luego no es problema de implementacion.

Tambien te encontras no solo con el WDT, sino con los flags que te indican porque el micro fue detenido.

[juaperser1]

Yo estoy totalmente de acuerdo con el comentario del creador de utask, es una de las partes mas importantes. Aunque como dice killer, hay que implementarlo al final, primero hay que probar todas las cosas que pueden salir mal, arreglarlas y dejar el programa superpulido. Despues se habilita el WDT para que este se ocupe de algo puntual que pueda ocurrir y que tu no puedas ni controlar ni predecir, yo que se.... que se rompa un cable en mitad de una transmisión, que caiga un rayo cercano, cualquier cosa que pueda pasar y que no puedas controlar.

es un sistema de seguridad final y en mi opinión nunca debe faltar, pero cuidado, tampoco se debe utilizar para reiniciar el micro por cualquier tonteria, si un programa esta bien hecho el WDT no debe saltar.

Es como el airbag del coche, no debe funcionar a no ser que pase un accidente.

un saludo

[planeta9999]

 

¿ Y como poneis el refresco del Watchdog, por aquí y por allá de manera anárquica en cada rutina, en el bucle del programa principal, con un timer para que se reinicie cada cierto tiempo ?.

Entiendo que pueda ser importante en entornos industriales, donde el fallo de un programa que controla máquinas, pueda provocar un desastre.

El problema es que tengo algunos diseños con tiempos críticos, usando DMA, y meter más cosas al programa, puede perjudicar más que ayudar.

Para mi lo que si es imprescindible es un buen bootloader encriptado, para poder corregir cosas y dar parches o nuevas versiones de firmware a distancia. El uTasker va genial (probado con Kinetis, lo quiero probar tambien con STM32), y para dar nuevas versiones de firmware al cliente, he creado un Github.

[juaperser1]

Y como poneis el refresco del Watchdog, por aquí y por allá de manera anárquica en cada rutina

Noooo, eso nunca, el WDT solo se refresca una vez en todo el programa, nunca en cada rutina ni en cada bucle... eso hace que tener el WDT y no tenerlo sea exactamente lo mismo, debes calcular cuanto tiempo maximo puede tardar tu programa en ejecutarse y poner un WDT que reinicie si tarda mas. si tu programa se queda parado en un bucle y el bucle lo esta reseteando de que te sirve?

no solo en entornos industriales, cualquier chisme que quiera tener un poco de calidad debe de poder reiniciarse solo en caso de que se quede pillado. No todos algunos procesos industriales necesitan un rearme manual para indicar que se ha visto el fallo y cosas asi, pero por norma general deberia estar en todos los sistemas, puede que haya alguna aplicación donde este prohibido pero debería estar en todos.

PD: Muy buen articulo, muy bien resumido y toda la razón.

PD2: cuando digo una sola vez en todo el programa, me refiero a una vez en cada ciclo del programa.

[Jorge555]

Ya que lo tienes es útil ponerlo, más aún en dispositivos que pueden pasar meses conectados sin intervención del usuario, pero como dice manwenwe, si todo está bien diseñado no debería saltar..

[planeta9999]

 

Del enlace original a embedded.fm, he mirado en esa web y se ven artículos interesantes:
http://embedded.fm/blog/embedded-wednesdays

Y en general todos los que están en el apartado "EMBEDDED WEDNESDAYS"
http://embedded.fm/blog/?tag=Embedded+Wednesdays

Como este sobre DMA.
http://embedded.fm/blog/2017/2/27/dma-examples

Creo que en cuanto domine un poco el DMA, podré hacer virguerías

[Nocturno]

Os recomiendo leer este mensaje de Azicuetano, yo para trabajos profesionales considero imprescindible lo de los checkpoints

http://www.todopic.com.ar/foros/index.php?topic=12418.msg70483#msg70483

[KILLERJC]

El tema esta en que realizar esos checkpoints y que te salte el programa al vector de reset es un problema.

En los PICs 16 y 18 no se resetearia el stack y por consiguiente pasa a un stack overflow. (agregar codigo de limpieza de stack en el archivo de inicializacion de C para evitar esto)
En los ARMs, dsPIC y PIC32 menos problemas con eso, pero no detectas nada ya que al iniciar todo de nuevo tenes tu variable en 0.

En lo unico util es cuando salte a otra seccion de codigo de forma inesperada, y pienso que eso implica que tenga una buena cantidad de memoria ocupada. Ademas no quita la posiblidad que salte en un lugar que sea:

- Cuando se hace 0 la variable
- Que coincida correctamente con el checkpoint que es de otra funcion sea con suma o no
- Que ocurra luego de la comparacion del checkpoint

Es cierto que aumentas un poco mas el grado de seguridad de tu codigo, pero no lo eliminas completamente, un refuerzo seria ademas utilizar valores variables en cada funcion.

La otra que queda para ayudar a eso de los checkpoints es llenar la memoria del integrado con saltos a loops infinito para que lo tome el WDT y conocer a ciencia cierta que el reset provino del WDT. En caso contrario de que llegue al vector de reset imlpica que no se detecte la falla. El resultado es lo mismo = reset, pero la diferencia es detectar o no la falla.

[Picuino]

No es frecuente que un microcontrolador se cuelgue (como el pantallazo azul en Windows), pero a veces pasa. En ese caso la máquina se quedaría inservible hasta que alguien venga y la resetee. Con un WDT no hace falta, se resetea sola y puede incluso guardar un log o enviar un mensaje con el fallo. Es mucho más profesional.

Saludos.

[planeta9999]

En ese caso la máquina se quedaría inservible hasta que alguien venga y la resetee. Con un WDT no hace falta, se resetea sola y puede incluso guardar un log o enviar un mensaje con el fallo. Es mucho más profesional.

¿ Y para que hace falta que alguien vaya a resetear un microcontrolador ?, lo desconectas de la corriente, lo vuelves a enchufar y arreando, el resultado será el mismo que el de un Watchdog, pero a mano.

No creo que la utilidad del Watchdog sea esa, sino proteger la periferia que maneja ese micro si falla. Seguro que hay entornos industriales, médicos y demás en los que puede ser crítico que una máquina se vuelva loca porque entre en un bucle o salte a una parte del programa sin control.

Lo que hará falta es que el programador de turno lo arregle y envíe una actualización por email, Skype, Telegram, etc... No hace falta desplazarse, a menos que sea una avería física.

[juaperser1]

  ¿ Y para que hace falta que alguien vaya a resetear un microcontrolador ?, lo desconectas de la corriente, lo vuelves a enchufar y arreando, el resultado será el mismo que el de un Watchdog, pero a mano. 

Imagina, Un almacen de congelados, el termostato se queda colgado a las 2 de la mañana, y se pierden miles de euros de productos que se han descongelado por que el programador dijo que era lo mismo desenchufar y enchufar manualmente que a que lo hiciera el propio micro.

[planeta9999]

 

Me refería a la necesidad de que un técnico se tenga que desplazar para resetear la unidad, o así lo entendí yo. Desconectas la unidad y la vuelves a conectar, no hace falta ningún técnico para eso, eso no suple las funciones del Watchdog, pero tampoco te obliga a llamar a nadie para reiniciar la unidad.

Precisamente la aplicación que yo entiendo es prioritaria en un Watchdog, es evitar desastres si una máquina se vuelve loca por entrar el programa en un bucle o saltar a una zona del programa sin control.

No he tenido ningún caso, en el que haya echado en falta el Watchdog, igual en el diseño de la ruleta lo pongo, no vaya a ser que la máquina se vuelva loca y empiece a dar monedas sin parar. Si diseñara aparatos médicos si que lo usaría sin dudarlo, o para controlar máquinas industriales,

[juaperser1]

A para ese caso si.

Yo te he puesto ese ejemplo precisamente por que la mayoría de mis proyectos son para medicina y sector de frio industrial, y ha pasado que muchos termostatos de los modelos antiguos se quedaban colgados y hacían un bloque de hielo o se derretía todo, el diseñador que lo hizo no puso WDT, tampoco es que hiciera bien el software por que se quedaban colgados muchas veces...

Prueba a usarlo en alguno de tus proyectos, no es muy difícil, tu haces tu software olvidandote del WDT y una vez que veas que esta correcto y como tu quieres activas el WDT y lo refrescas una sola vez en el bucle while, no tiene mucho trabajo pero si muchos beneficios.

Un saludo