¿El reinicio del ciclo de encendido es diferente del reinicio del pin de reinicio?

Estoy usando arduino uno personalizado para un proyecto de automatización del hogar. A veces, el arduino se bloquea debido a ruidos eléctricos o chispas en las líneas de CA. Más detalles aquí .

Traté de realizar algunas pruebas controladas para saber más sobre esto, donde dejé el módulo encendido e hice todo lo posible para introducir el mayor ruido posible al encender/apagar los interruptores y girar las perillas del regulador del ventilador. También traté de apagar el circuito usando un encendedor de gas mientras el circuito estaba encendido. Hice una configuración que me permitía hacer saltar chispas en cualquier parte de la PCB que quisiera. Hice esto porque no podía pagar un arma de simulación de ESD.

Después de todo esto, pude hacer que mi microcontrolador colgara después de torturarlo durante unos minutos y pude repetir el proceso de colgar. Éxito hasta esta parte.

Una vez que mi microcontrolador se congela, a veces puedo devolverlo al proceso normal tirando del pin de reinicio BAJO, pero la mayoría de las veces no puedo. Es como si el pin de reinicio no funcionara en absoluto. Sin embargo, puedo devolverlo a su funcionamiento normal encendiéndolo.

(De lo contrario, el pin de reinicio funciona bien cuando se está ejecutando la ejecución normal del código. El pin de reinicio tiene un diodo de extracción y protección según lo recomendado por la hoja de datos de atmega. Desacoplamiento solucionado. Tapas de filtro muy cerca de los pines de alimentación. osciloscopio también).

¿El reinicio del ciclo de encendido es diferente en comparación con el reinicio del pin de reinicio? ¿Es este un comportamiento esperado? ¿Puedo hacer algo para asegurarme de que mi pin de reinicio siempre funcione en tales condiciones?

La diferencia entre el reinicio y el ciclo de encendido en un arduino depende en gran medida de cómo el circuito Arduino Uno trata el pin de reinicio de Atmel, cómo está configurado el Atmel y qué está programado para hacer el cargador de arranque de arduino antes de saltar al boceto. Para la mayoría de las personas no hay diferencia. Para algunos, es útil saber que un reinicio es muy parecido a una interrupción donde (ciertos) registros Atmel se borran/establecen. Lo más probable es que una actividad similar a un reinicio o un reinicio sea parte de un ciclo normal de encendido de Arduino.
¿Salen chispas de la fuente de alimentación de CA...? Te refieres a transitorios, espero.
De todos modos, diseñar una PCB que pueda manejar "chispas en cualquier parte de la PCB" es todo un desafío. No elegiría exactamente un microcontrolador aficionado para requisitos tan difíciles. Las pruebas normales de ESD involucran chispas en cajas, protectores y conectores de metal. Las contramedidas son un buen diseño EMC y una resistencia en serie desde cada pin del conector. No hace falta decir que la MCU necesita una resistencia de tracción en el pin de reinicio, y también una tapa, con un valor recomendado por el fabricante.
@Lundin: las chispas no provenían de la fuente de alimentación de CA, pero pensé que podrían estar ocurriendo dentro de electrodomésticos como refrigeradores y reguladores de ventiladores donde existe la posibilidad de arco eléctrico por contacto. Lo más probable es que fueran transitorios. Sin embargo, quería replicar el bloqueo en la mesa y esta parecía ser la única opción que podría forzar a la mcu a un estado bloqueado. Como señalaron otros, esto podría no ser lo mismo que estaba causando los bloqueos y, por lo tanto, es difícil concluir algo a partir de esto.

Respuestas (4)

¿El reinicio del ciclo de encendido es diferente en comparación con el reinicio del pin de reinicio?

Sí. Hay algunos comportamientos de semiconductores en los que solo la pérdida de energía permitirá que se reanude el comportamiento anterior. Un SCR es un tipo de componente donde este comportamiento (es decir, solo la pérdida de energía permite que se reanude el estado anterior) es normal, y existen estructuras similares a SCR en la mayoría de los circuitos integrados.

¿Es este un comportamiento esperado?

Depende de lo que quieras decir con " esto ". ¿Es el comportamiento esperado que puede provocar una situación extrema usando descargas ESD de voltaje desconocido en un circuito vivo, donde solo se recuperará un ciclo de energía? Sí

¿Puedo hacer algo para asegurarme de que mi pin de reinicio siempre funcione en tales condiciones?

Siempre , por las condiciones de esa prueba? Siendo realistas, no, sin medidas extremas.

Según su descripción, sospecho que su inyección de ESD está activando el bloqueo, a veces llamado bloqueo SCR (o un comportamiento similar al bloqueo ) dentro de la MCU. Texas Instruments tiene una buena nota de aplicación llamada Latch-Up, ESD y otros fenómenos que contiene información muy relevante para sus preguntas.

Iba a responder a su pregunta anterior que vinculó, pero demasiados detalles no estaban claros para mí, algunas decisiones se basaron en suposiciones con las que no estaba de acuerdo y la experiencia me dice que es poco probable que pueda agregar mucho en esa situación. Tampoco creo que su prueba actual sea realista, en el contexto de sus problemas descritos en la pregunta anterior.

Después de todo esto, pude hacer que mi microcontrolador colgara después de torturarlo durante unos minutos y pude repetir el proceso de colgar. Éxito hasta esta parte.

Respetuosamente no estoy de acuerdo con que esto sea "éxito". Lo que ha hecho es provocar un síntoma similar a su pregunta anterior (es decir, bloqueos de MCU). Pero hay varias causas raíz posibles para ese síntoma: ¿cómo sabe que está provocando la misma causa con la pistola ESD que con su dispositivo instalado en la ubicación planificada? No hubo evidencia en su pregunta anterior de chispas ESD directas en la PCB viva (que es una prueba extrema); sin embargo, eso es lo que está probando ahora.

Por lo tanto, veo los resultados de su prueba ESD actual como un problema XY. Tiene el problema original con el bloqueo de MCU. Aún no fuiste capaz de diagnosticar eso. Ahora ha encontrado otra forma de activar el bloqueo de MCU (usando chispas ESD directas). Pero eso no significa que las chispas directas de ESD sean la causa de su problema original (por lo tanto, no llamaría a ESD desencadenar un bloqueo de MCU como un "éxito"), ni significa que cualquier arreglo diseñado para ayudar con la protección de ESD sería ayuda con su problema original tampoco.

Me doy cuenta de que esto suena negativo, lo siento. Solo estoy sugiriendo que, en base a muchos años de experiencia en la resolución de problemas de sistemas complejos, es muy probable que esté "cayendo en un agujero de rata" al seguir sus pruebas actuales, ya que es posible que no ayude con su problema original .

Personalmente, si estuviera en su situación, me concentraría en diagnosticar mejor el problema original , en lugar de presentar un caso de prueba nuevo (y creo que poco realista). ¡Toda la suerte!

Para agregar una experiencia personal fuera de tema sobre cuán grave puede ser un problema de bloqueo de ESD: una vez hice una pasantía en una empresa que producía interruptores de línea eléctrica. Necesitaba pasar una inyección de 12Kv esd en un conector. De vez en cuando, obteníamos un comportamiento increíble, como datos en serie falsos, etc. Una vez, incluso conseguimos que el temporizador de vigilancia independiente y el circuito de supervisión se bloquearan. Incluso los perros guardianes no son infalibles en situaciones de ESD. Al final, después de ejecutar más de 2000 pruebas, nos dimos por vencidos.
Muchas gracias por esta hermosa respuesta. Estoy de acuerdo en que fue un poco extremo. Creí que el ruido era la causa raíz de mis problemas y pensé que las chispas esd eran la mejor forma de ruido. Sin embargo, con respecto al diagnóstico, ¿qué debo hacer? ¿Lo instalo y espero una semana (que podría extenderse hasta un mes) para que se congele? El problema con esto es que no podré saber cuál fue el problema exacto. Ya probé dispositivos de supresión WDT y esd. Como mencionó @ DC177E, he experimentado lo mismo. Solo me pregunto cómo lo hacen los demás. ¿Existen métodos predefinidos?
Una mejor protección ESD y EMI transmitida es realmente la única ruta. Cajas de metal, cuentas de ferrita, amortiguadores, diodos TVS, etc.
Nuevamente fuera de tema, pero @pjc50 El dispositivo que estábamos probando tenía: Una ruta directa al plano de tierra con un cable grueso, un escudo de metal sobre la mayoría de los circuitos, una caja de acero de 0,25 pulgadas de grosor, una ferrita alrededor del conector blindado, un TVS en cada línea de datos y una configuración de inductor-condensador sintonizado en cada línea de datos para atenuar algo de la hf. Todavía tenemos bloqueos cada pocas descargas.
@Whiskeyjack - "Creí que el ruido era la causa raíz" - [de su problema original] - muy probable, pero el ruido! = chispas de ESD. || "¿Hay algún método predefinido?" - ¿Para solucionar problemas? ¿O supresión/tolerancia al ruido? Sí a ambos, pero hay libros completos sobre cada tema, demasiado para caber aquí. || "con respecto al diagnóstico, ¿qué debo hacer?" - Una vez más, demasiado para caber en un comentario, y hay muchas incógnitas sobre sus limitaciones. Sin embargo, veo brechas [preguntas anteriores] en el proceso de reproducir el problema en condiciones controladas y correlacionar el tiempo de falla con los eventos.
gracias sam Me diste muy buena información para empezar. Intentaré mejorar el circuito tanto como pueda usando la teoría disponible. Esto parece un proceso constante de aprendizaje y acción.

Como usuario de Arduino, sospecho que está muy lejos en el campo izquierdo. El Arduino es notablemente IN sensible a los transitorios. Y si de todos modos le preocupan los transitorios que llegan a través de la fuente de alimentación, puede colocar un supresor de sobretensiones (o un UPS) en la entrada de alimentación. Si está realmente preocupado por los transitorios que vienen por el aire, simplemente debe proteger el Arduino (tal vez con una asadera de aluminio).

Sin embargo , según mi experiencia, lo que es mucho más probable es que ocasionalmente todas sus salidas sucedan al mismo tiempo, y el consumo total de corriente sea demasiado y, por lo tanto, provoque que el voltaje regulado disminuya. Caer a 4V en lugar de 5V por solo unos pocos milisegundos casi garantiza que el Arduino Uno se cuelgue. Una forma de solucionar esto es mirar cuidadosamente todas sus salidas y ver si alguna de ellas consume mucha corriente o tiene un retraso inductivo, y reorganizar a los infractores. Otra forma de solucionarlo es agregar un poco de complejidad a su software haciendo una cola de cambios "deseados" y luego haciendo solo uno de estos cambios a la vez cada enésima llamada a loop(). De esa manera nunca tendrás demasiado sucediendo al mismo tiempo.

Aunque sospecho que su pregunta es completamente irrelevante para sus bloqueos, aquí está la respuesta: la placa Arduino Uno está diseñada para hacer lo contrario de lo que hacen la mayoría de los chips (incluido el chip Arduino): con Arduino Uno, un ciclo de encendido no lo hará. hacer mucho; de hecho, dejará el programa intacto. Así es como mueve un Arduino desde su banco de desarrollo/prueba al lugar donde se implementará. Un reinicio, por otro lado, borrará todo por completo y esperará una nueva descarga. Si las cosas están lo suficientemente jodidas como para que el pequeño programa del cargador de arranque Arduino en la placa no funcione correctamente, entonces el reinicio será manejado solo por el chip, y el resultado podría ser el comportamiento que ves.

Exactamente lo que sucederá después de que su tipo de cuelgue no esté bien definido. En lugar de tratar de solucionar el síntoma, solucione la causa para que nunca se encuentre en esta situación en primer lugar.

Si tiene mucha mala suerte y no puede averiguar el origen de los bloqueos, es posible que deba agregar algún código de rastreo de depuración o algún registro a su programa. Por ejemplo, puede registrar cada entrada en cualquier función. Luego, cuando se cuelga, solo vea cuál fue el último mensaje de rastreo, y sabrá que el problema está en algún lugar de esa subrutina (probablemente más especialmente si ocurrió una interrupción al mismo tiempo).

(Ah, y si hay más de una fuente de alimentación [incluida una que no es obvia porque es parte de un sensor remoto y la que está dentro de la placa Arduino Uno], asegúrese de conectar todas las conexiones negativas/tierras juntas. De lo contrario, una la fuente de alimentación puede "flotar" y, por ejemplo, proporcionar entradas analógicas que están fuera de rango).

(También preste atención si el compilador advierte sobre una operación "inestable" porque se usa demasiado espacio de datos. En un Arduino no hay protección contra el desbordamiento de la pila. Puede tener suficiente espacio libre para todas las operaciones normales, pero si ocurre una interrupción exactamente cuando la ejecución es muy profunda y tiene una pila muy grande, puede desbordarse. Los datos se escribirán en el espacio. Eso no es un gran problema hasta que intente leerlo y no está allí. Por lo general, la función en la que se encuentra de alguna manera sigue ejecutándose, pero cuando finaliza y "regresa", la dirección de retorno tampoco se puede leer y, por lo tanto, será aleatoria y, en esencia, su código "irá" a alguna ubicación aleatoria. Esto a menudo resulta en un bloqueo).

Restablecer o apagar y encender un procesador no debería ser una actividad normal. Un procesador aparentemente bloqueado es una buena indicación de que existe un problema de software o hardware.

Arduinos no es la plataforma de depuración ideal, pero mire a través de su código y el mensaje de impresión de depuración para determinar la actividad del código durante la ejecución normal y durante el bloqueo.

Compruebe su fuente de alimentación para posibles mejoras. Ejecute sus pruebas mientras ejecuta temporalmente el Arduino con baterías.

Compruebe si está sobre las entradas de conducción. Los circuitos digitales pueden bloquearse si el voltaje presentado en cualquier pin es más alto que el voltaje de suministro al chip.

Finalmente, hay una característica común llamada perro guardián que, como último recurso/protección, reinicia el procesador. Suele ser un temporizador físico externo (al procesador) que. Sin embargo, algunos procesadores lo tienen incorporado. Diseñe con el entendimiento de que un perro guardián es una protección y no algo que se usa durante el funcionamiento normal.

Aquí hay una discusión sobre un perro guardián implementado en el software Arduino. no lo he estudiado. Si se trata de un perro guardián físico dentro del Atmel, probablemente sea útil. Si es solo una implementación de software, puede ser útil.

Añadido más tarde...

Encontré esta página web sobre la detección del bloqueo de Arduino. Se habla de un perro guardián.

Esto sería aplicable a situaciones normales, sin embargo, es poco probable que un Arduino común o cualquier otro circuito que no esté específicamente blindado contra ellos a nivel de placa sobreviva a las pruebas de encendido piezoeléctrico mencionadas. No se debe esperar que sigan funcionando, o que necesariamente vuelvan a funcionar después.
WDT no funcionó. La única suerte que tuve fue el pin de reinicio que parece estar desapareciendo. @ChrisStratton - Gracias por comentar. Sí, estoy de acuerdo con tu punto. No haré eso. Sin embargo, todavía estoy desconcertado por lo que podría estar pasando dentro de la mcu que evita que se reinicie incluso cuando el pin de reinicio está bajo.

Si el silicio está diseñado para ello y toda la lógica de la placa está diseñada para ello y la placa está diseñada para ello, entonces debería poder reiniciar. Un avr definitivamente no está en esa clase de partes, ya que tiene una lógica específica que solo funciona cuando se reinicia. por lo tanto, restablecer no es una solución para que un avr se confunda con esd. necesita restablecer el control de energía y hacer que apague y encienda el avr, el tiempo suficiente para volver a ponerlo en un estado conocido.

la interfaz de programación en circuito en avr está activa cuando el chip está reiniciado. lo que significa que hay una lógica que tiene un reinicio de encendido separado y solo usa el pin de reinicio como entrada (y/o el pin de reinicio en el estado afirmado es que la lógica no ha reiniciado).