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

Question

Una variedad particularmente irritante de error en un sistema controlado por un microprocesador es que el microprocesador se reinicie inesperadamente. Una herramienta importante para depurar este tipo de problema es una lista de posibles causas. ¿Qué podría causar que un microcontrolador se reinicie inesperadamente?

Answer 1

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

Hardware:

• El pin de reset se mantiene bajo o flotante. ¡Verifica primero las cosas obvias!
• Acoplamiento ESD en el pin de reset. He visto que esto sucede cuando se enciende equipo completamente no relacionado en el mismo escritorio. Asegúrate de tener suficiente capacitancia en el pin de reset, posiblemente hasta 1 uF.
• Acoplamiento ESD en otros pines del procesador. Las puntas de osciloscopio en particular pueden actuar como antenas, acoplar ruido en el chip y causar resets extraños. He escuchado informes de códigos de reset de "instrucción no válida".
• Mala junta de soldadura/puente intermitente. Podría estar perdiendo o cortocircuitando un riel de alimentación, ya sea en el procesador o en otro lugar en la placa.
• Glitch/ruido en el riel de alimentación. Podría ser causado por cualquier número de problemas externos, incluyendo un regulador dañado o una caída en la fuente upstream. Asegúrate de que los rieles de alimentación que alimentan el procesador sean estables. Puede requerir más capacitores en algún lugar, tal vez un capacitor de desacople directamente en el procesador.
• Algunos microcontroladores tienen un pin Vcap, que no debe estar conectado a VDD y debe tener su propio capacitor a común. No conectar este pin correctamente puede tener resultados impredecibles.
• Conducir una entrada analógica negativa más allá de un límite específico causa un reset que se informa en RCON como un brownout. Lo mismo puede ser cierto para las entradas digitales.
• Un dV/dt muy alto en un convertidor de potencia cercano puede causar un reset de brownout. (Ver esta pregunta.) He visto esto en dos casos, y en uno pude rastrearlo hasta el acoplamiento capacitivo. Un IGBT estaba conmutando 100-200 amperios, y al apagar algunas señales de retroalimentación veían unos microsegundos de ruido, pasando de 2V a más de 8V en un procesador de 3.3V. Aumentar el capacitor en ese riel de retroalimentación hizo que los resets se detuvieran. 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úrate de que el temporizador de vigilancia se limpie lo suficientemente a menudo, especialmente en ramas de tu código que pueden tomar mucho tiempo en ejecutarse, como las escrituras en EEPROM. Prueba esto deshabilitando el temporizador de vigilancia para ver si el problema desaparece.
• División por cero. Si estás realizando alguna operación de división en tu código, asegúrate de que el divisor nunca pueda ser igual a cero. Agrega una verificación de límites antes de la división. No olvides que esto también se aplica a las operaciones de módulo.
• Stack Overflow. Demasiadas llamadas a funciones anidadas pueden hacer que el sistema se quede sin memoria dinámica para la pila, lo que puede llevar a fallas en puntos inusuales de la ejecución del código.
• Debajo de flujo de pila. Si estás programando en ensamblador, puedes ejecutar accidentalmente más RETURNs de los que ejecutaste CALLs.
• Rutina de interrupción inexistente. Si una interrupción está habilitada, pero no se define una rutina de interrupción, el procesador puede resetearse.
• Rutina de trampa inexistente. Similar a una rutina de interrupción, pero lo suficientemente diferente como para listarla por separado. He visto dos proyectos separados que utilizan dsPIC 30F4013 que se reiniciaron aleatoriamente, y la causa se rastreó a una trampa que se llamó pero no estaba definida. Por supuesto, ahora tienes la pregunta de por qué se llama a una trampa en primer lugar, que podría ser cualquier número de cosas, incluido un error de silicio. Pero definir todos los controladores de trampa probablemente debería ser un buen paso temprano en el diagnóstico de resets inexplicados.
• Fallo de puntero de función. Si un puntero de función no apunta a una ubicación válida, desreferenciar el puntero y llamar a la función a la que apunta puede causar un reset. 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 entero). La coma se escribió incorrectamente, por lo que el puntero de función realmente se inicializó a NULL-1. ¡Así que no asumas que solo porque es una CONST debe contener un valor válido!
• Índice de array inválido/negativo. Asegúrate de hacer una verificación de límites en todos los índices de los arrays, tanto en los límites superiores como en los límites inferiores, si corresponde.
• Crear un array de datos en la memoria del programa que sea más grande que la sección más grande de la memoria del programa. Esto puede que ni siquiera genere un error de compilación.
• Convertir la dirección de una estructura a un puntero a otro tipo, desreferenciar ese puntero y usar el puntero desreferenciado como el LVALUE en una declaración puede causar un fallo. Ver 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 reset. Esto puede ser muy útil durante la depuración.

Answer 2

El pin de RESET debe ser correctamente controlado por un circuito de reinicio que monitorea sobre/subtensión y que crea una señal de reinicio lo suficientemente larga. Con eso en mente, mis experiencias con un reinicio de hardware no controlado provienen de:

• Interferencias de líneas de conmutación en el pin/línea de RESET (hacerlas cortas)
• Cambios en tierra/bucle causados por la activación/desactivación de carga externa de alto corriente
• Pico de voltaje no filtrado por la fuente de alimentación y demasiado corto para activar el RESET adecuadamente
• Conmutación de cargas externas por el microcontrolador que causa los problemas anteriores (principalmente en cargas inductivas como motores de encendido/apagado, relés o lámparas antiguas (corriente de entrada)
• Picos de voltaje/corriente en cualquiera de los pines del microcontrolador (peor es el oscilador) pueden causar corriente inversa y pueden cambiar registro(same as voltage spikes on the supply line). En general, al interactuar con un entorno industrial, se necesita aplicar cautela (para más información, ver: http://www.ichaus.biz/wp1_mcu_interface). Es necesario considerar el cambio de niveles en IOs, el filtrado de entrada y la conmutación suave de salidas. Hacer que las líneas de suministro estén limpias tiene la primera prioridad en el lado del hardware. Luego los pines de RESET y oscilador, y luego las líneas de IO. -mm

Answer 3

Una posibilidad adicional que no vi en esta lista, es un dispositivo que admita ICSP. Si no se utilizan suficientes resistencias pull-up en las líneas que activan el modo de programación en serie en circuito, a veces es posible entrar en ese modo de forma aleatoria. Esto conduce a un reinicio un corto tiempo después cuando no se envía ninguna actualización de programa a las líneas receptoras seriales designadas. Sospecho que un temporizador interno de vigilancia fuerza un reinicio si se inicia ICSP y no se envían datos de programación. Este es un error que he cometido y he pasado mucho tiempo tratando de encontrar con un 16F876.

Answer 4

Asegúrate de que si estás utilizando chips lógicos CMOS o TTL en tu circuito, tengan capacitores de desacople adecuados entre Vdd y tierra (generalmente 0.1 uF). Estaba utilizando un CD4021 en un diseño y cuando estaba en uso, aparentemente estaba causando alguna oscilación que provocaba que el microprocesador se reiniciara. Luego el ciclo se repetiría. Por eso también es una buena idea poner una secuencia de prueba obvia (como hacer parpadear un LED varias veces) al inicio de tu código para saber que el microprocesador está funcionando y ejecutando el código.

Answer 5

Este es uno de esos raros eventos que pueden surgir:

Tenía un proyecto que involucraba un microcontrolador y ocasionalmente se reiniciaba. En resumen, resulta que alguna opción debía ser habilitada o deshabilitada, de lo contrario podrían producirse reinicios. Solo me enteré de esto al leer la errata después de haber renunciado a todo lo demás.

Ahora hago un hábito de leer la errata antes siquiera de decidirme a utilizar un chip, para saber en qué me estoy metiendo y si es algo que puedo manejar. Desafortunadamente, después de graduarme, no tuve realmente a nadie que me educara sobre 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.