Autor Tema: WATCHDOG SÍ O WATCHDOG NO??  (Leído 10561 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado DarkVect

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 302
WATCHDOG SÍ O WATCHDOG NO??
« en: 19 de Febrero de 2007, 17:23:07 »
Hola,

A raíz de este post http://www.todopic.com.ar/foros/index.php?topic=13890.0 en el que se discute sobre la forma de realizar un reset completo del PIC, me ha entrado una duda acerca del uso o no del WATCHDOG.

¿Es realmente necesario proteger el sistema frente a un "cuelgue" del PIC? ¿Qué probabilidades hay de que se "cuelgue"? Hasta el momento siempre lo he dashabilitado y no he tenido ningún problema jamás de que una aplicación se quede colgada, pero me ha entrado el miedo!!

¿Es aconsejable ponerlo? ¿En qué casos?

Gracias a todos!!

Desconectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5544
    • Picmania by Redraven
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #1 en: 19 de Febrero de 2007, 17:37:03 »
Hablando en funcion de la corta experiencia que llevo haciedo "cacharros" profesionalmente puedo decirte que:

* En el laboratorio no hace falta el WachDog para nada.

* En el mundo real de las interferencias, los ruidos, las condiciones reales en las que tienen que funcionar si que hace falta.

Cuando un PIC, y toda la electrónica que lo rodea, se monta en entornos de motores,variadores de frecuencia, cargas reactivas, líneas de alimentación alterna, emisores de todo tipo de radiofrecuencias y campos electromagnéticos y hasta cargas estáticas, cuando el PIC se conecta a sensores, o a otros dispositivos electronicos, o incluso a su propia fuente de alimentación está rodeado de antenas que recogen absolutamente todo lo que pueda perturbarles.

En entornos de este tipo lo extraño es que funcione bien. Es imprescindible un diseño cuidadoso de nuestra PCB, con sus planos de masa, sus condensadores de desacoplo, (ver el magnifico articulo de Chaly sobre el tema), es imprescindible también afinar el firmware para que deseche o descarte los ruidos que puedan interferirlo, es imprescindible usar líneas con malla para evitar que las señales se contaminen de ruidos ...

y si todo falla es necesario disponer de un watchdog que vuelva a colocar al PIC en orden de marcha.

Al menos esa ha sido mi experiencia en dos de cada diez casos a los que me he enfrentado. Y según me dicen los fabricantes de otros equipos con los que integro los míos esto va e irá siempre a peor.


« Última modificación: 19 de Febrero de 2007, 17:39:37 por RedPic »
Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18286
    • MicroPIC
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #2 en: 20 de Febrero de 2007, 03:07:25 »
¿Es aconsejable ponerlo? ¿En qué casos?

Yo diría que desde que Murphy publicó sus leyes siempre es aconsejable. Al fin y al cabo no cuesta nada ponerlo y si nunca tiene porqué funcionar, pues no está de sobra.

Desconectado DarkVect

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 302
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #3 en: 20 de Febrero de 2007, 06:40:19 »
Queda claro que es recomendable ponerlo por si acaso.

Lo he probado pero no me funciona bien.

El código es este:

#include <16LF84A.h>                               //pic a utilizar
#fuses XT, WDT, NOPROTECT, PUT                   //ordenes para el programador
#use delay (clock=3276800)                         //Fosc=3,2768Mhz
#use fast_io(a)
#use fast_io(b)

//Funciones de interrupción Timer0 e INT_EXT

void main(void)
{
   disable_interrupts(GLOBAL);                     //deshabilitar interrupciones
   ext_int_edge(H_TO_L);                           //interrupcion en flanco de bajada
   setup_TIMER_0(RTCC_INTERNAL | RTCC_DIV_128);    //preescaler=128 para 1seg
   setup_wdt(wdt_18ms);
   
   set_tris_a(0b00000000);                         //porta todo como salida
   set_tris_b(0b11111111);                         //portb todo como entrada
   enable_interrupts(INT_EXT);                     //interrupcion del reed del anemo
   enable_interrupts(INT_TIMER0);                  //interrupcion del contador
   enable_interrupts(GLOBAL);                      //interrupciones activadas
   
   do
   {
       restart_wdt();
       actividades();
    }while(TRUE);
}

Actividades() lo forman pocas instrucciones que duran mucho menos que los 18ms del Watchdog pero el PIC se va reiniciando. Según he leído en el Datasheet no puedo escalar el Watchdog porque ya estoy usando el preescaler para el Timer0 y en el 16F84 es incompatible escalar ambos.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #4 en: 20 de Febrero de 2007, 07:46:18 »
Me sumo a las sugerencias de los amigos Diego y Manolo de aconsejarte el uso del Watchdog.   Vivimos a miles de km de distancia y aún así hemos llegado a las mismas conclusiones que no las relataré ya que el amigo Diego las expuso en forma breve y precisa.

Los tiempos del watchdog son bastante precisos, ¿qué tanto más pequeño que 18mseg es esa funcion actividades?

¿Acaso no tienes algún salto a interrupción que pueda demorar su tiempito? Ojo con esto.  También si tienes algún delayms(20) bueno, esto es candidato a que ocurra un watchdog :)

El uso del watchdog preveé de cuelgues en el hardware por causas externas pero no evitará que tu software haga cualquier cosa si está mal hecho.  Y depende donde pongas el reset del watchdog (por ej, si lo ubicas en un vector de interrupción activado por un timer) nunca se reseteará no importa qué cosas hagas en el código normalmente (excepto desactivar el GIE). 

Saludos
- La soberbia de un Einstein es entendible.. la de un salame es intolerable (A.Dolina)
- En teoría no hay diferencia entre la teoría y la práctica. En la práctica... si la hay.
- Lee, Lee, Lee y luego pregunta.(maunix)
- Las que conducen y arrastran al mundo no son las máquinas, sino las ideas (V. Hugo)
- Todos los hombres se parecen por sus palabras; solamente las obras evidencian que no son iguales.(Moliere)
- Todo debería ser hecho tan simple como sea posible pero no mas simple que eso.(A.Einstein)

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #5 en: 20 de Febrero de 2007, 11:58:12 »
Hola DarkVect!

Fíjate hasta donde llega mi nivel de paranoia con los cuelgues de los PIC´s que mira lo que hago en todos mis programas (los que ven la luz de forma comercial claro).

http://www.todopic.com.ar/foros/index.php?topic=12418.0

No me atrevo a sacar ningún equipo al mercado sin hacerle esto. Es muy paranoico poor mi parte pero... por las noches duermo a pierna suelta sabiendo que hardware/software es incolgable jeje.

PD: Núnca se sabe donde se van a colocar nuestros cacharros. Imagínate que alguien lo pone justo encima de una máquina de soldadura por arco o... en cualquier otro sitio peor  :D


Un saludo desde Alicante.

Desconectado reiniertl

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1187
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #6 en: 20 de Febrero de 2007, 12:49:38 »
   
   do
   {
       restart_wdt();
       actividades();
    }while(TRUE);
}


Prueba lo siguiente en este fragmento de código, sustituye actividades(); por algo como encender y apagar un LED o hacer sonar un piezo, lo que te propongo es que compruebes si tu WD realmente está reseteando al PIC o eres tú el que se pasa de tiempo. Si actualmente estás simulando o tienes un debugger en caliente, entonces te darás cuenta rápidamente, sino es así te aconsejo poner una demora antes de activar el WD y correr el código que sustituye a actividades();

De todas formas creo que es muy probable que te estés pasando del tiempo de restart del WD. Por ejemplo si usas un printf(), es muy probable que te pases de ese tiempo, una función con demoras, pues también te pasas con facilidad de ese tiempo, 18ms no es mucho tiempo, así que tienes que hilar bien fino tu código para resetear el WD antes de que el sea el que te resetee al uC.

Lo esencial que debes conocer al trabajar con un WD, es que se parece al PacMan, (un juegito viejo que muchos foreros arcanos conocen y otro no tanto también). Pues en ese juego debes correr y correr...... y hacerlo muy bien, para que no te coman. En tu caso es lo mismo, si tu código no le da tiempo a la función que resetea el WD para que haga su trabajo, te aseguro que el WD no tendrá piedad y adiós.

Por ejemplo: pónte como meta que cada tarea que ejecutes lo haga en menos de 15ms antes de llamar a restart_wdt(), así le dejas tres a restart_wdt(), al do...while() para que compruebe la expresión lógica y te queden algunos us de respaldo para cualquier ruta crítica que demore un poquito la ejecución.

Otra cosa que puedes hacer es mover la temporización para otro Timer, así le dejas el preescalador al WD solito y puedes poner un período más largo para el reset. Si no te alcanzan los Timer para dejarle el preescalador al WD, entonces múdate para un uC con más Timers,  Microchip tiene tal variedad que eso no será problema.

saludos Reinier

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18286
    • MicroPIC
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #7 en: 20 de Febrero de 2007, 13:00:39 »
Me ha gustado mucho tu mecanismo anti-cosas-raras, Azicuetano.

Me apunto la idea; además también sirve para debuggear los programas.

Desconectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5544
    • Picmania by Redraven
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #8 en: 20 de Febrero de 2007, 15:43:33 »
Ivan:

Tengo una instalación que me está volviendo loco ... y tus "checkpoints" van a ser como agua bendita caída del cielo.  :mrgreen:

Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado ESTECA55

  • PIC24H
  • ******
  • Mensajes: 1404
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #9 en: 20 de Febrero de 2007, 17:18:08 »
Muy bueno el sitema Azicuetano!! lo voy a tener presente.

Hay que esforzarse por ser el mejor, no creerse el mejor

Desconectado DarkVect

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 302
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #10 en: 20 de Febrero de 2007, 19:23:12 »
Gracias por las respuestas.

Mañana probaré con un ejemplo básico el funcionamiento del Watchdog a ver dónde me estoy equivocando.

Sólo tengo una duda. Programando en CCS, dónde se asigna el preescaler para el timer0 o para el watchdog? Como veis tengo la función setup_timer_0() en la que se asigna un preescaler para el timer0 pero luego utilizo la función setup_wdt() en la que asigno el periodo del watchdog. Supongo que si en esta última función no pones algo diferente de 18ms el CCS ya se encarga de mantener el preescaler para el timer0 y que si le pones algo diferente lo cambia. Es así? Es necesario poner setup_wdt() si vas a usarlo a 18ms?

Otra cosa que me me "choca" es que teniendo el timer0 preescalado no puedas prácticamente usar la función delay_ms() debido al "pequeño" periodo del watchdog. En un programa más o menos largo habría que refrescarlo cada varias líneas, en cada interrupción o función adicional, etc...

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #11 en: 20 de Febrero de 2007, 20:27:24 »
Hola gente!

Explicaré un poco mejor de que me han salvado mis 'checkpoints'. Además del caso que he comentado en el link que he puesto un poco más arriba tengo otra situación un tanto curiosa.

Teniamos un equipo que consta de varias PBA´s conectadas entre si. El caso es que una vez me llamó un operario diciendome que una de las PBA´s se reiniciaba cuando se enchufaba el equipo. Era una cosa que núnca me habia pasado y me puse a hacerle pruebas como un loco al cacharro.

Una o dos de cada 10 veces que encendíala el equipo la maldita PBA se reseteaba. Al final me di cuenta que el operario había cortado el cable de alimentación demasiado largo y... se paseaba por encima de la PBA que se reiniciaba (el cable de 220V de la red tocaba la PBA y el lomo del micro).

Mi compañero se estaba comiendo un bocata y... ni corto ni perezoso le pedí el papel de aluminio con el que tenía envuelto el bocadillo. Apantalle la PBA y todo fenomeno paranormal dejó de suceder. Quité el papel de aluminio y otra vez con los reinicios, es decir, era el cable de 220V seguro.

Muy bien... por que os he contado todo este rollazo?? Pues porque mi software tenía implementado el 'checkpoint securty system' jejej y gracias a el la PBA se daba cuenta del salto en el contador de programa debido al ruido y se autorreiniciaba. Cogí una versión del software sin los chequpoint y... puufff!!! como fallaba la cosa. Con el software sin checkpoints en lugar de reiniciarse se pegaba unas colgadas de escandalo.

Entonces fué cuando decidí incluir este sistema en todos mis programas. Así evitamos que el ruido, ya sea por un mal diseño, por una mala colocación del equipo, o por lo que sea que se nos escape del entendimiento electrónico cuadrado que tenemos, nos cuelgue nuestos queridos cacharros.

Otro proyecto en el que puedo contrastar la eficacia de los checkpoints es en una fuente de alimentación que implementé y que tenía unos cuantos relés. Antes de descubrir los truquillos para evitar el ruido de los relés hice un montón de prototipos que fallaban más que una escopeta de feria. Al final conseguí un diseño del cual nunca he detectado nungún cuelgue pero... despues del buen resultado que me dieron los checkpoints decidí implementarlos también en este diseño.

Lo que hize fue... coger el peor diseño que tenía (uno de los primeros que insolé y que tenía un índide de cuelgues sobrehumano) e implementé el checkpoint security system hasta que conseguí que el equipo no se me colgara núnca. Tenía muchísimo ruido por los relés pero lo detectaba y rearmaba la fuente (tan rápido que el usuario no se daba ni cuenta). Cuando el equipo con el diseño malo se paso una semana encendido y funcionando a la perfección, cogí ese software y lo metí en el diseño bueno.

Nunca detecté ningún cuelgue en el hardware final que hice pero ademas... con el nuevo software que ya tenía y que era capaz de soportar tantos cuelgues, mi seguridad en el equipo es total. Se puede colgar? Pues a lo mejor si, pero, la probabilidad es ínfima. Resultado?? Iván duerme a pierna suelta todas las noches sin ningún miedo a que llamen clientes furiosos jejej  :D :D

Bueno, os invito a que lo probeis. A mi me da muy buenos resultados.

PD: Diego, intenta implementarlo que ya verás como te puedes evitar un monton de problemas. Puedes hacer 2 cosas:

Cosa 1 -> Cuando detectes que la cuenta de checkpoints no se ha hecho correctamente, llama a una función que se quede en un bucle infinito con algún parpadeo característico y con refresco de Watchdog. Así la próxima vez que veas el equipo podras saber si es por el motivo del ruido los cuelgues.

Cosa 2 -> Cuando detectes que la cuenta de checkpoints no se ha hecho correctamente, llama a una función que resetee el PIC pero antes guarda en la eeprom el número de cuelgues. Así tras unas semanas de funcionamiento podrás distinguir si los cuelgues son por el ruido y el índice de reseteos que ha tenido el equipo.


Ufff... que panzá de escribir jejeje. Un saludo desde Alicante!

Desconectado flacoclau

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1692
    • El Micro Reactor
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #12 en: 20 de Febrero de 2007, 21:04:17 »
Estas ideas geniales alegran mi vida :-)
saludos.
Las personas con buena ortografía me atraen textualmente.

El Micro Reactor

Córdoba capital - Argentina.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #13 en: 21 de Febrero de 2007, 00:12:23 »
Azicuetano es probable que en caso ese de la interferencia de los 220V en realidad tuvieras problemas con el oscilador.   Si usas un cristal metálico, prueba soldar su chasis a GND.

Saludos
- La soberbia de un Einstein es entendible.. la de un salame es intolerable (A.Dolina)
- En teoría no hay diferencia entre la teoría y la práctica. En la práctica... si la hay.
- Lee, Lee, Lee y luego pregunta.(maunix)
- Las que conducen y arrastran al mundo no son las máquinas, sino las ideas (V. Hugo)
- Todos los hombres se parecen por sus palabras; solamente las obras evidencian que no son iguales.(Moliere)
- Todo debería ser hecho tan simple como sea posible pero no mas simple que eso.(A.Einstein)

Desconectado DarkVect

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 302
Re: WATCHDOG SÍ O WATCHDOG NO??
« Respuesta #14 en: 21 de Febrero de 2007, 14:54:41 »
COMPROBADO:

El preescaler común del watchdog y del timer0 de algunos PIC se asigna, como era de esperar, al que hace la llamada a su función setup en último lugar. Es decir, si ponemos:

setup_timer_0(...);
setup_wdt(...);          //el preescaler es para el watchdog y viceversa para el caso contrario

Lo he comprobado con un led que se encendía al pulsar un botón y debía estar encendido durante 20 segundos temporizados con el timer0. En el main se refrescaba el watchdog constantemente.

Si el preescaler lo utilizaba el timer0 todo iva perfecto. Si éste era para el watchdog el led se encendía y apagaba de inmediato, ya que el timer sin el reescaler daba un periodo muy corto.

Además he añadido una rutina infinita: while(TRUE){} para ver si el watchdog actuaba y todo ha ido bien.

Una pregunta a los que hacéis programas "largos": ¿qué mecanismo usáis para ir refrescando el watchdog? Me refiero a cada cuánto lo hacéis, si lo hacéis también en las rutinas de interrupción, etc...

Gracias a todos!!
« Última modificación: 21 de Febrero de 2007, 15:45:00 por DarkVect »