Misterioso problema de conducción de carga a través de NFET con microcontrolador

Question

U1 es un microcontrolador que acciona M1 para accionar una carga. Me estoy encontrando con algunos comportamientos extraños y voy a tratar de incluir toda la información pertinente. Espero que no sea demasiado.

• M1 es un FET de nivel lógico.
• U1 funciona con una alimentación de 3,3 V derivada de la batería de 3,7 V del sistema. Hay no otras fuentes de alimentación conectadas, como fuentes de alimentación de sobremesa. Todas comparten una toma de tierra común.
• Aunque he dibujado la carga como una resistencia, eso fue más de que no vi otra opción en CircuitLab para la carga genérica de caja negra. Literalmente estoy conduciendo una carga de caja negra también, uno de esos generadores de alto voltaje que puedes comprar en eBay como celui-ci . Mi entendimiento es que la entrada de la primera etapa dentro de su cavernoso epoxied interiores es una especie de oscilador de bloqueo, y por lo que es totalmente posible que esta carga no es puramente resistiva. Sólo tenlo en cuenta, pero hasta ahora no creo que sea inductiva ya que no he tenido ningún problema de fiabilidad con como back-EMF destruyendo el FET como si hubiera un solenoide dentro de la caja.
• La carga consume mucha corriente, unos 2 A.

Esto es lo que pasa:

1. Estoy haciendo esto en una protoboard. Si conecto VGATE directamente a la alimentación de 3,3 V a U1 (lo que el GPIO está tirando a), funciona bien.
2. Cuando acciono un pulsador que acciona un ISR para subir la puerta, lo hace muy brevemente y luego el circuito integrado se reinicia (hago que el código parpadee con un LED diferente al arrancar para saber que se ha reiniciado). Esto me hizo sospechar una caída de tensión en las líneas de alimentación debido a la repentina sobretensión de la batería.
3. Para solucionar el supuesto droop de alimentación, añadí un montón de condensadores de desacoplamiento tanto en el lado de entrada del regulador lineal LDO como en el de salida. Esto pareció ayudar un poco, pero aún así sólo impulsaría la carga durante menos de un segundo y luego se reiniciaría.
4. Añadí un LED a la salida y sorprendentemente esto pareció ayudar. Tal vez se carga el GPIO un poco más, la reducción de la velocidad de giro de tensión en VGS y por lo tanto la reducción de la caída de suministro?

Ahora es cuando las cosas se ponen raras:

• Si conecto una sonda de Analizador Lógico a VGATE (quería ver cómo eran las ondas), ¡funciona completamente! Maldito seas, Werner Heisenberg.

He hecho algunos experimentos y no importa si se conectan tanto la sonda de señal como la de tierra o sólo una (cualquiera de las dos, no parece importar). Sí, un solo cable sin camino de retorno para la corriente está afectando de alguna manera esto. ¿Podría ser alguna cosa extraña de la antena, o el acoplamiento de ruido en el cable que podría estar haciendo algo? Voy a decir que desde que estoy breadboarding, mis cables son cada vez un poco largo, nada más largo que 6 "sin embargo.

Tampoco importa si el analizador lógico está conectado a mi ordenador o no (analizador lógico USB, Saleae Logic Pro, por si importa). Al principio pensé que quizás había diferentes potenciales de tierra, aunque esperaría que la tierra del analizador estuviera aislada del puerto USB de mi PC. De cualquier manera, con un solo cable conectado no veo cómo la corriente puede estar fluyendo dentro o fuera de ese cable de todos modos y por lo tanto hacer nada.

En fin, que me estoy dando cabezazos contra la pared intentando resolver esto y he pensado que a veces no es bueno trabajar en el vacío. Gracias a quien me pueda ayudar.

EDITAR: Probando de nuevo la idea de que el acoplamiento CGD podría estar apagando el FET, intenté hacer la tapa a masa allí más grande con una tapa en VGATE a masa. Aunque esto no funcionó, noto que si sólo toco la parte superior de la tapa (es electrolítica), el circuito funciona de nuevo sin problemas.

Entonces, tocando con mi cuerpo la parte superior de la tapa se soluciona el problema. Poner un cable de un analizador lógico en esa red (ya sea GND o VGATE) soluciona el problema. Y poner una carga de LED en el pin GPIO también ayuda (pero no lo arregla del todo).

¿Qué teoría podría explicar a los tres y por qué lo arreglan?

EDIT2: Llegando a alguna parte... tomando la sugerencia de Spehro de que el di/dt de conmutar una carga tan grande podría acoplarse inductivamente, puse un filtro RC grande en VGATE para que limitara el di/dt de conmutación. Lo que encuentro es que, todo lo demás sin cambios, el LED en el GPIO lentamente se atenúa más brillante hasta que el FET está completamente encendido, y cuando el HVGEN chispea, el micro se reinicia. Si grabas un video del circuito en un teléfono, la imagen es ruidosa debido a la gran EMI.

Básicamente creo que la EMI de las chispas está reiniciando el microcontrolador independientemente de los picos di/dt u otros eventos como este. Por alguna razón cuando toco el condensador en VGATE, el problema desaparece. ¿Es posible que yo sea un cuerpo grande que "absorbe" la EMI de alguna manera y por lo tanto el micro no se reinicia?

Si es así, ¿cómo puedo solucionarlo de forma permanente, sin tocar el circuito en todo momento? ;) ¿Hay alguna manera sin encerrar todo el circuito impreso en una jaula de Faraday?

Answer 1

Ten en cuenta que en la hoja de especificaciones del IRF530 (una marca IR más antigua) el voltaje umbral de la puerta (activación de la puerta) se muestra de 2 V como mínimo a 4 V como máximo. Así que tu línea de E/S de 3,3V podría no ser tan adecuada. El mosfet puede aparecer como una parte de nivel lógico, pero esto sólo puede estar relacionado con 5V lógica de E / S. Así que con una puerta marginal cualquier ruido adicional en la puerta (acoplado inductiva o capacitivamente) podría hacer una gran diferencia.... Ver: irf.com/product-info/datasheets/data/irf530.pdf . Si el microcontrolador que estás utilizando es capaz de funcionar a un nivel de 5V, inténtalo para confirmar el problema del accionamiento de la puerta.

También puede colocar tapones de derivación (en este caso valores más altos, tal vez 100uf o más) justo en el punto de +V de la "Carga" a tierra. Esto ayudaría a proporcionar una alta corriente inicial a la carga y evitar aún más que los picos negativos lleguen al regulador. (Si esa es la causa del problema de Reset)

Answer 2

Aunque todas las respuestas aquí expuestas fueron útiles para la depuración, ninguna de ellas resultó ser la historia completa.

En resumen: necesitaba blindar el microcontrolador contra las interferencias electromagnéticas con una jaula de Faraday.

Como señalé en mi segunda edición, al poner una carga de puerta excesiva en el MOSFET para limitar el di/dt se demostró que no era el pico de corriente (ya que lo limité limitando Vgs slewrate), sino que cuando el dispositivo chispeaba, la EMI del dispositivo hacía que se reiniciara.

La sugerencia de Spehro de no hacer esto en una protoboard era acertada, y un diseño adecuado en una PCB profesional (incluyendo muchos más decaps y técnicas adecuadas de conexión a tierra en estrella). hizo ayudar drásticamente al problema. Estas técnicas por sí solas permitirían que el dispositivo funcionara sin reiniciarse, siempre y cuando el HVGEN no estuviera directamente encima del microcontrolador.

Sin embargo, al colocar la unidad directamente sobre la placa de circuito impreso (la unidad HVGEN está totalmente aislada), seguía habiendo suficiente EMI que la disposición adecuada no podía superar y volvía a reiniciarse.

La única cosa que lo arregló para siempre, incluso con él sentado directamente en la parte superior era un escudo EMI como celui-ci . Afortunadamente puse una huella en mi PCB para esto, por si acaso, esperando no tener que rellenarla, pero hacerlo fue el truco. Una jaula de Faraday completa alrededor del microcontrolador solucionó el problema.

Answer 3

Sabes que no deberías hacer este tipo de cosas en una protoboard.

Prueba a añadir una resistencia de unos 10K en serie con la puerta. Es posible que estés recibiendo picos acoplados desde el drenaje a la puerta que están alterando el micro, o picos por debajo del suelo debido a la inductancia de la configuración de tu protoboard. O hay un condensador de bypass en la caja negra que si se cambia demasiado rápido hará que el micro se reinicie.

Puedes diagnosticar esto último si pones un interruptor pulsador de la puerta al +3.7 (desconecta el pin del puerto) con el micro funcionando -sólo esa conexión rota- y ves si pulsando el interruptor unas cuantas veces se reinicia el micro (el 10K descargará la carga de la puerta).

Haz también las conexiones entre la fuente, la batería (-) y el cable de tierra que va a la protoboard fuera de la protoboard, o al menos utiliza un conjunto aislado de conexiones para unirlas en un (y sólo un) punto, que luego se puentea a cada uno de los tres.