¿Qué podría hacer que un microcontrolador se reinicie inesperadamente?

En los chips PIC y dsPIC, he observado las siguientes causas de reinicio inesperado.

Hardware:

• Restablecimiento del pin bajo o flotante. ¡Comprueba las cosas obvias primero!
• acoplamiento ESD en el pin de reinicio. He visto que esto sucede cuando se enciende un equipo completamente no relacionado en el mismo escritorio. Asegúrese de que haya suficiente capacitancia en el pin de reinicio, posiblemente hasta 1 uF.
• acoplamiento ESD en otros pines del procesador. Las sondas de alcance en particular pueden actuar como antenas, acoplar el ruido en el chip y causar reinicios impares. He escuchado informes de códigos de restablecimiento de "código de operación no válido".
• Junta de soldadura defectuosa / puente intermitente. Podría estar perdiendo o cortocircuitando un riel eléctrico, ya sea en el procesador o en algún otro lugar de la placa.
• Fallo / ruido en el carril de alimentación. Podría ser causado por cualquier número de problemas externos, incluido un regulador dañado o una caída en el suministro corriente arriba. Asegúrese de que los rieles de alimentación que alimentan el procesador estén estables. Puede requerir más tapa en alguna parte, tal vez desacoplar la tapa directamente en el procesador.
• Algunos microcontroladores tienen un pin Vcap, que no debe estar conectado a VDD y debe tener su propio capacitor común. Si no se conecta correctamente este pin, se pueden obtener resultados impredecibles.
• Al pasar un negativo de entrada analógica más allá de cierto límite, se produce un restablecimiento que informa en RCON como un apagón. Lo mismo puede ocurrir con las entradas digitales.
• Un valor de dV / dt muy alto en un convertidor de potencia cercano puede provocar un restablecimiento de la salida de corriente. (Consulte esta pregunta .) He visto esto en dos casos, y en uno pude rastrearlo hasta un acoplamiento capacitivo. Un IGBT estaba cambiando de 100 a 200 amperios, y al apagar algunos circuitos de realimentación estaban viendo unos pocos microsegundos de ruido, pasando de 2V a más de 8V en un procesador de 3.3V. Al aumentar la tapa del filtro en ese riel de retroalimentación, los reinicios se detuvieron. Uno podría imaginar que agregar un filtro dV / dt a través del transistor podría haber tenido un efecto similar.

Software:

• temporizador de vigilancia. Asegúrese de que el temporizador de vigilancia se borre con la frecuencia suficiente, especialmente en las ramas de su código que pueden tardar mucho tiempo en ejecutarse, como las escrituras de EEPROM. Prueba esto desactivando el perro guardián para ver si el problema desaparece.
• Dividir por cero. Si está realizando la operación de división cualquiera en su código, asegúrese de que el divisor nunca pueda ser igual a cero. Agregar una verificación de límites antes de la división. No olvide que esto también se aplica a operaciones de módulo .
• Desbordamiento de pila. Demasiadas llamadas a funciones anidadas pueden hacer que el sistema se quede sin memoria dinámica para la pila, lo que puede provocar fallos en puntos inusuales en la ejecución del código.
• Pila de desbordamiento. Si está programando en ensamblador, puede ejecutar accidentalmente más DEVOLUCIONES que ejecutó CALLs.
• Rutina de interrupción inexistente. Si se habilita una interrupción, pero no se define ninguna rutina de interrupción, el procesador puede reiniciarse.
• Rutina de captura no existente. Similar a una rutina de interrupción, pero lo suficientemente diferente, la enumero por separado. He visto dos proyectos separados usando dsPIC 30F4013 que se reiniciaron al azar, y la causa fue rastreada hasta una trampa que fue llamada pero no definida. Por supuesto, ahora tiene la pregunta de por qué se llama una trampa en primer lugar, lo que podría ser cualquier cosa, incluido el error de silicio. Pero la definición de todos los manejadores de trampas probablemente debería ser un buen paso para diagnosticar reinicios inexplicables.
• Fallo del puntero de función. Si el puntero de una función no apunta a una ubicación válida, eliminar la referencia al puntero y llamar a la función apuntada puede provocar un restablecimiento. Una causa divertida de esto fue cuando estaba inicializando una estructura, con valores sucesivos de NULL (para un puntero de función) y -1 (para un int). La coma se tipificó, por lo que el puntero de la función se inicializó a NULL-1. ¡Así que no asuma que solo porque es un CONST debe contener un valor válido!
• Índice de matriz no válido / negativo. Asegúrese de realizar la comprobación de límites en todos los índices de matriz, tanto los límites superiores como , si corresponde.
• Creando una matriz de datos en la memoria del programa que es más grande que la sección más grande de la memoria del programa. Esto ni siquiera puede lanzar un error de compilación.
• Convertir la dirección de una estructura en un puntero a otro tipo, eliminar la referencia de ese puntero y usar el puntero de no referenciado como LVALUE en una declaración puede provocar un bloqueo. Consulte esta pregunta . Presumiblemente, esto también se aplica a otros comportamientos indefinidos.

En algunos dsPICs, el registro RCON almacena bits que indican la causa del restablecimiento. Esto puede ser muy útil al depurar.

El pin RESTABLECIMIENTO debe ser accionado apropiadamente por un circuito de reinicio que supervisa sobre / bajo voltaje y crea una señal de reinicio lo suficientemente larga. Teniendo esto en cuenta, mis experiencias con un reinicio de hardware no controlado provienen de:

• La interferencia de las líneas cambiadas al pin / línea RESET (hacerlas cortas)
• Desplazamientos / bucles a tierra causados por el encendido / apagado de la carga de alta corriente externa
• El pico de voltaje no se filtra por la fuente de alimentación y es demasiado corto para activar el REAJUSTE adecuado
• Conmutar las cargas externas por el microcontrolador que causa los problemas anteriores (principalmente en las cargas inductivas, como el encendido / apagado del motor, los relés o la lámpara vieja (corriente de entrada)
• El pico de voltaje / corriente en cualquiera de los pines del microcontrolador (el peor es el oscilador) puede causar una corriente inversa y puede cambiar el registro interno (igual que los picos de voltaje en la línea de suministro). En general, cuando se debe establecer una interfaz con un tipo de entorno industrial, se debe aplicar precaución (para obtener más información, consulte: enlace ). Se debe considerar el cambio de nivel en las E / S, el filtrado de entrada y las salidas de conmutación suave. Hacer que las líneas de suministro estén limpias tiene la primera prioridad en el lado del hardware. Luego RESET y pines del oscilador, luego líneas IO. -mm

Una posibilidad adicional que no vi en esta lista es un dispositivo que admita ICSP. Si no se utilizan pull ups insuficientes en las líneas que se activan en el modo de programación en serie del circuito, a veces es posible ingresar ese modo al azar. Esto lleva a un reinicio un breve intervalo más tarde cuando no se envía ninguna actualización del programa a las líneas de receptor serie designadas. Sospecho que las fuerzas del temporizador de vigilancia interna se reinician si se inicia ICSP y no se envían datos de programación. Este es un error que cometí y pasé mucho tiempo buscando con un 16F876.

Asegúrese de que esté utilizando chips lógicos CMOS o TTL en su circuito, que tengan capacitores de desacoplamiento adecuados a través de Vdd y tierra (generalmente 0.1 uF). Estaba usando un CD4021 en un diseño y cuando estaba en uso, aparentemente estaba causando un pico que estaba haciendo que el microprocesador se reiniciara. Entonces el ciclo se repetiría. Esta es la razón por la que es una buena idea poner una secuencia de prueba obvia (como encender y apagar un LED varias veces) al inicio de su código para que sepa que el microprocesador está funcionando y ejecutando el código.

Esta es una de esas cosas raras que pueden aparecer:

Tenía un proyecto que involucraba un microcontrolador y se reiniciaba esporádicamente. Larga historia corta, resulta que alguna opción tenía que estar habilitada o deshabilitada, de lo contrario podrían ocurrir reinicios. Solo lo descubrí leyendo la errata después de renunciar a todo lo demás.

Ahora hago un hábito de leer la errata antes de decidir usar un chip para saber en qué me estoy metiendo y si es algo que pueda manejar. Desafortunadamente, después de graduarme, realmente no tenía a nadie que me informara sobre las prácticas comunes, por lo que gran parte de mi aprendizaje en el mundo real ha sido a través del fracaso y la frustración ".