Estoy usando controladores PIC, y he usado temporizadores de vigilancia para activar un reinicio en caso de que el software se atasque en alguna parte, y también para brindar soporte en caso de fallas graves de hardware. Creo que restablecer la CPU es bueno, pero informar el bloqueo también debería ser una muy buena opción viable para ayudar a la depuración. Actualmente estoy buscando un método para hacerlo. Dispongo de una EEPROM con espacio libre para tal fin.
Además de la sugerencia de Nick de usar the, RCONque es muy útil, aquí hay algunas otras ideas/indicadores que debe tener en cuenta:
Asegúrese de verificar la resistencia de la EEPROM si siempre está escribiendo datos en la misma ubicación. Incluso si tiene una resistencia de 1,000,000 millones de ciclos si su sistema puede iniciarse en 100 ms, no se necesitaría mucho más de un día de reinicios constantes para causar una falla de EEPROM si recibe reinicios constantes debido a conexiones inestables/alimentación, etc. Tal vez considere un retraso para reinicios que no sean de vigilancia o introduzca un retraso a propósito para evitar esa posibilidad.
Otra forma (probablemente más fácil / mejor) de evitar ese problema es reservar un área de EEPROM en bloques de tamaño fijo y usar un marcador al comienzo del bloque para indicar si se ha utilizado (valor no 0xFF) y simplemente dejar de registrar errores una vez la memoria está llena. Luego, después de que se haya leído el registro de errores, borre todo para que esté listo para la próxima vez.
En el caso de un reinicio del perro guardián, el contenido de la RAM seguirá intacto. Necesitaría probar/verificar/cambiar esto para el compilador particular que está usando, pero en el caso de un reinicio de vigilancia, le daría la posibilidad de registrar el valor de algunas de las variables de estado más importantes como parte del informe de error. . Muchos compiladores ponen a cero el contenido de la RAM al inicio, por lo que deberá verificar ese lado de las cosas. Sin embargo, deberá ignorar el contenido de la memoria para otros tipos de reinicio.
Algún tipo de marca de tiempo será valiosa en un análisis posterior. Obviamente, un RTC que proporcione una fecha/hora absoluta sería ideal, pero si no está disponible, tal vez podría incluir algún tipo de contador de ticks para al menos dar una idea relativa del lapso de tiempo entre fallas.
Siempre puede leer y registrar el valor de las líneas de E/S y las entradas analógicas y registrarlas al reiniciar, pero tenga en cuenta que su valor puede haber cambiado desde la condición inicial que causó el bloqueo.
Dependiendo del espacio de código y el rendimiento que le quede libre, si conserva el contenido de algunas ubicaciones de RAM durante un reinicio de vigilancia, también podría considerar agregar un número entero o una máscara de bits para indicar qué código/interrupciones se llamaron justo antes de la condición de error.
Los PIC proporcionan un método para que el firmware determine la causa de un reinicio. Hay un registro RCON. Tiene bits para el siguiente reset causado
Mire el capítulo 4.1 en la hoja de datos para PIC18F2525. No sé qué modelo específico de PIC está utilizando, así que consulte la hoja de datos para su PIC específico.
chris stratton