El puerto COM se cae inesperadamente, pero Arduino Leonardo sigue funcionando

Observo un comportamiento extraño con mi tablero Leonardo.

Utilizo un adaptador de CA/CC de 9 V para alimentarlo. La placa de extensión de relés está conectada a pines digitales y los relés se utilizan para controlar varias válvulas y motores.

He dejado solo un pequeño motor de CA de 220V 0.2A para probar. Se conecta al mismo enchufe de pared que el adaptador de 9V. Arduino se conecta al portátil con un cable USB corto equipado con un anillo de ferrita.

Ahora, aquí está mi problema: al usar la conexión en serie, enciendo y apago el relé varias veces y la conexión del puerto COM muere tarde o temprano. La ventana de PuTTY muestra un error, el puerto COM permanece en la lista del administrador de dispositivos de Windows, pero no puedo restablecer la conexión a menos que desconecte y vuelva a conectar el cable USB. Sorprendentemente, Leonardo sigue funcionando. Estoy seguro de que no se reinicia: agregué un pitido a la configuración () para escuchar cuándo lo hace.

Podría ser el ruido causado por las bobinas del motor que interfiere con el adaptador de CC; no tengo condensadores en ellos. (Y no es la placa de relés, tiene diodos para la bobina de cada relé). Mi pregunta es diferente:

No me sorprendería tanto si fuera Arduino UNO. Pero Leonardo tiene un solo chip para las comunicaciones USB y el trabajo, por lo que si uno falla, el segundo también debería hacerlo, ¿verdad?

¿Cómo podría estar pasando?

Me parece que el problema es su computadora portátil y el adaptador de USB a serie, a juzgar por sus referencias a masilla y un puerto COM. ¿Puedes poner un alcance en la línea TX del Arduino y decirnos lo que ves?
@JoeHass Arduino Leonardo tiene USB integrado en MCU (ATMega32u4). OP: ¿quizás podrías revisar los registros USB para ver qué está pasando?
La presencia del dispositivo de puerto COM en el Administrador de dispositivos de Windows puede ser complicado a veces, esto también sucede con FTDI a veces, es decir, el dispositivo aparece incluso después de perder la comunicación. La presencia solo indica que el controlador del dispositivo todavía está cargado en la memoria. Entonces, si no puede comunicarse con leonardo a través de COM, eso podría significar un error en nombre de la comunicación del controlador de CDC (poco probable) o su leonardo podría ser golpeado en alguna parte (probable). Un analizador lógico (o un analizador USB) puede ayudarlo a encontrar el problema real.
Lo he solucionado (más o menos). Probablemente, el problema estaba relacionado de alguna manera con el módulo de reloj RTC DS1307 defectuoso y/o la cantidad de memoria SRAM que usaba mi boceto. He tenido problemas con Leonardo que no sincroniza su temporizador con RTC en el 50 % de los casos, eliminé esta funcionalidad de mi código, liberé alrededor de 1 Kb de SRAM, y ahora funciona sin problemas. Probablemente, si estuviera usando UNO, habría reiniciado, pero dado que Leonardo es diferente, estaba "medio congelado".
Tuve el mismo problema al intentar controlar un motor con un mosfet lógico conectado al pin3 digital y monitorear los datos de velocidad del monitor en serie... Estoy casi seguro de que el problema es el ruido del mosfet del motor... porque el puerto en serie está nunca se pierde si el motor no está funcionando... Se pierde algún tiempo después de encender el motor (12v de un suministro diferente, compartiendo tierra)... pero el script continúa funcionando... solo se pierde el puerto serie...
Arduino proporciona dos puertos. Uno es para el cargador de arranque y está activo solo durante el primer segundo. El otro es para la biblioteca arduino usbserial. Aparecieron como dispositivos separados en ventanas con diferentes números de puerto. He tenido problemas para bloquear la biblioteca en serie cuando la aplicación se detiene
Leonardo tiene un historial de bloqueos de Serial COM... principalmente debido al lado del host/controlador...

Respuestas (2)

Aunque son el mismo chip, los circuitos USB y MCU pueden funcionar de forma independiente. Por ejemplo, la parte USB se puede usar para restablecer la parte MCU.

Lo he solucionado (más o menos).

Probablemente, el problema estaba relacionado de alguna manera con el módulo de reloj RTC DS1307 defectuoso y/o la cantidad de memoria SRAM que usaba mi boceto. He tenido problemas con Leonardo que no sincroniza su temporizador con RTC en el 50 % de los casos, eliminé esta funcionalidad de mi código, liberé alrededor de 1 Kb de SRAM, y ahora funciona sin problemas.

Probablemente, si estuviera usando UNO, habría reiniciado, pero dado que Leonardo es diferente, estaba "medio congelado".

Claro, es bastante fácil colapsar la pila USB de una MCU, tanto que el USB tiende a no funcionar para la salida de depuración en los casos en que el firmware está demasiado dañado. También es completamente posible que el ruido eléctrico convenza a un concentrador para que apague el puerto que está utilizando.