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

Una variedad particularmente irritante de error en un sistema controlado por 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?

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

Hardware:

• Restablecer el pasador 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 tanto como 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 provocar reinicios extraños. He escuchado informes de códigos de restablecimiento de "código de operación no válido".
• Mala junta de soldadura / puente intermitente. Podría estar perdiendo o poniendo en cortocircuito un riel de alimentación, ya sea en el procesador o en otro lugar de la placa.
• Falla / ruido del riel 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 aguas arriba. Asegúrese de que los rieles de alimentación que alimentan el procesador sean estables. Puede requerir más capacidad en alguna parte, quizás desacoplando la capacidad directamente en el procesador.
• Algunos microcontroladores tienen un pin Vcap, que no debe estar conectado a VDD y debe tener su propio condensador en común. No conectar este pin correctamente puede tener resultados impredecibles.
• Conducir una entrada analógica negativa más allá de cierto límite provoca un reinicio que informa en RCON como un apagón. Lo mismo puede ser cierto para las entradas digitales.
• Un dV / dt muy alto en un convertidor de potencia cercano puede provocar un reinicio por caída de voltaje. (Vea esta pregunta .) He visto esto en dos casos, y en uno pude rastrearlo hasta el acoplamiento capacitivo. Un IGBT estaba cambiando de 100 a 200 amperios, y al apagarse algunos circuitos de retroalimentación estaban viendo unos pocos microsegundos de ruido, pasando de 2V a más de 8V en un procesador de 3.3V. El aumento de la tapa del filtro en ese riel de retroalimentación hizo que los reinicios 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úrese de que el temporizador de vigilancia se borre con la suficiente frecuencia, especialmente en las ramas de su código que pueden tardar mucho tiempo en ejecutarse, como las escrituras EEPROM. Pruebe esto deshabilitando el watchdog para ver si el problema desaparece.
• Dividir entre cero. Si está realizando una operación de división en su código, asegúrese de que el divisor nunca pueda ser igual a cero. Agregue una verificación de límites antes de la división. No olvide que esto también se aplica a las 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 bloqueos en puntos inusuales en la ejecución del código.
• Pila de flujo inferior. Si está programando en ensamblador, puede ejecutar accidentalmente más RETORNOS de los que ejecutó LLAMADAS.
• Rutina de interrupción inexistente. Si se habilita una interrupción, pero no se define una rutina de interrupción, el procesador puede reiniciarse.
• Rutina de trampa inexistente. Similar a una rutina de interrupción, pero lo suficientemente diferente, la estoy enumerando por separado. He visto dos proyectos separados usando dsPIC 30F4013 que se reiniciaron aleatoriamente, y la causa fue rastreada a una trampa que se llamó pero no está definida. Por supuesto, ahora tiene la pregunta de por qué se llama una trampa en primer lugar, que podría ser cualquier cantidad de cosas, incluido el error de silicio. Pero la definición de todos los manejadores de trampas probablemente debería ser un buen primer paso para diagnosticar restablecimientos inexplicables.
• Falla del puntero de función. Si el puntero de una función no apunta a una ubicación válida, desreferenciar el puntero y llamar a la función apuntada puede provocar un reinicio. 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 tipeó, por lo que el puntero de función en realidad se inicializó a NULL-1. ¡Así que no asuma que solo porque es un CONST debe contener un valor válido!
• Índice de matriz inválido / negativo. Asegúrese de realizar la verificación de límites en todos los índices de matriz, tanto superiores como los límites inferiores, si corresponde.
• Crear una matriz 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 ni siquiera arrojar un error de compilación.
• Convertir la dirección de una estructura en un puntero a otro tipo, desreferenciar ese puntero y usar el puntero desreferenciado como LVALUE en una instrucción puede provocar un bloqueo. Ver esta pregunta . Presumiblemente, esto también se aplica a otros comportamientos indefinidos.

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

El pin de RESET debe ser conducido adecuadamente por un circuito de reinicio que supervisa el voltaje excesivo / bajo 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:

• Interferencia de líneas de conmutación en el pin RESET / línea (hacerlas cortas)
• Desplazamientos a tierra / bucle causados ​​por la activación / desactivación de la carga de alta corriente externa
• Pico de voltaje no filtrado por la fuente de alimentación y demasiado corto para activar el RESET adecuado
• Cambio de cargas externas por el microcontrolador que causa los problemas anteriores (principalmente en cargas inductivas como encendido / apagado del motor, relés o lámpara vieja (corriente de entrada)
• El pico de voltaje / corriente en cualquiera de los pines del microcontrolador (lo peor es el oscilador) puede causar corriente inversa y puede cambiar el registro interno (igual que los picos de voltaje en la línea de suministro). En general, al interactuar con un tipo de entorno industrial, se debe tener precaución (para más información, consulte: http://www.ichaus.biz/wp1_mcu_interface ). Es necesario tener en cuenta el cambio de nivel en las E / S, el filtrado de entrada y las salidas de conmutación suave. Limpiar las líneas de suministro 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 compatible con ICSP. Si se utilizan pull ups insuficientes en las líneas que se disparan 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 de tiempo más tarde cuando no se envía ninguna actualización del programa a las líneas de receptor serie designadas. Sospecho que un temporizador de vigilancia interno fuerza el reinicio 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 si está utilizando chips lógicos CMOS o TTL en su circuito que tengan condensadores 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 causando que el microprocesador se reiniciara. Entonces el ciclo se repetiría. Esta es también la razón por la cual es una buena idea poner una secuencia de prueba obvia (como encender y apagar un LED varias veces) al comienzo de su código para que sepa que el microprocesador está funcionando y ejecutando 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. En pocas palabras, resulta que alguna opción tuvo que habilitarse o deshabilitarse; de ​​lo contrario, podrían producirse reinicios. Solo descubrí esto leyendo la errata después de renunciar a todo lo demás.

Ahora me acostumbro a leer las erratas antes de decidir usar un chip para saber en qué me estoy metiendo y si es algo que puedo manejar. Desafortunadamente, después de graduarme, realmente no tenía a nadie que me educara sobre prácticas comunes, por lo que gran parte de mi aprendizaje en el mundo real se debió al fracaso y la frustración.