Los informes se bloquean / reinician en sistemas integrados (8 bits)

Además de la sugerencia de Nick de usar RCON , que es muy útil aquí, hay otras ideas / sugerencias que debes 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 tomará mucho más de un día de reinicios constantes para causar un fallo de EEPROM si obtiene reinicios constantes debido a conexiones / alimentación inestables, etc. Quizás considere una demora para reinicios que no sean de vigilancia o introduzca una demora en la elección del usuario 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 inicio del bloque para indicar si se ha utilizado (valor no 0xFF) y simplemente deja de grabar errores una vez que la memoria está llena. Luego, una vez que se haya leído el registro de errores, borre todo, así que es bueno continuar la próxima vez.

• En el caso de un restablecimiento de watchdog, el contenido de la RAM seguirá intacto. Necesitaría probar / verificar / cambiar esto para el compilador particular que está utilizando, pero en el caso de un reinicio de vigilancia, se podría registrar el valor de algunas de las variables de estado más importantes como parte del informe de errores. . Muchos compiladores ponen a cero el contenido de la RAM en el 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 dar una fecha / hora absoluta sería ideal, pero si no está disponible, tal vez podría incluir algún tipo de contador de tics para al menos dar una idea relativa del intervalo 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 sobren si conserva el contenido de algunas ubicaciones de RAM en un reinicio de vigilancia, también podría considerar agregar un entero o una máscara de bits para indicar qué código / interrupciones se llamaron solo antes de la condición de error.

Los PIC proporcionan un método para que el firmware determine la causa de un restablecimiento. Hay un registro RCON . Tiene bits para el siguiente reinicio causado

• El firmware se reinició a sí mismo a través de una instrucción de reinicio
• Ocurrió el tiempo de espera de WDT
• se produjo el encendido en el reser
• Ocurrió un reinicio de reducción de disponibilidad

Consulte el capítulo 4.1 en la hoja de datos de PIC18F2525. No sé qué modelo específico de un PIC está utilizando, así que consulte la hoja de datos de su PIC específico.