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?
¿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!
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.
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.
st2000
Lundin
Lundin
whiskyjack