Los controladores del chip de interfaz usb-serial "CH340" causan problemas de reinicio de AVR en Windows/Linux

Después de algunas investigaciones con un osciloscopio, descubrimos que el chip de interfaz CH340 USB-Serial en este dispositivo Nano V3.0 (un chip común para clones de arduino baratos) se ve obligado a restablecerse 5 veces por su controlador de dispositivo de Windows durante la enumeración USB.

El controlador de dispositivo de Linux también hace que se reinicie con la enumeración USB, pero solo envía un pulso de reinicio.

El paquete de batería tonto no tiene líneas de datos ni concepto de enumeración y, en consecuencia, no se reinicia, lo que permite que el Nano se inicie normalmente y funcione correctamente.

Aquí hay una comparación del pin serial "DTR" del CH340 unos segundos después de insertar el cable USB en Windows y Linux...

En el Nano V3.0, la señal DTR está acoplada en CA al pin de reinicio del ATMega328P. ¡Entonces, por cada flanco descendente en esos rastros, el chip ATMega328P se reinicia! Por alguna razón, pasar por estos reinicios estaba poniendo el Nano en un estado desconocido

La solución para aquellos de nosotros que queremos usar un Nano V3.0 SIN necesidad de compatibilidad con Arduino IDE es simplemente desoldar el pequeño condensador de montaje en superficie conectado al pin 13 en el CH340 en el dispositivo Nano V3.0 . Eso es todo.

Esto aún permitirá que Windows y Linux se comuniquen con el dispositivo a través de la interfaz serial y le permite alimentar el dispositivo desde un suministro externo de 5V y conectarlo a una PC sin que el Nano se reinicie.

Para nosotros, nuestros dispositivos ahora funcionan bien con Atmel Studio + JTAGICE 3 y se inician correctamente sin importar a qué los conectemos.

Conclusión: Puede ser deseable que algunas aplicaciones hagan que el Nano se reinicie solo cuando lo conectas a una PC, pero parece que esta "característica" está causando un funcionamiento no deseado del dispositivo en nuestro caso. El hecho de que el controlador de Windows se comporte de manera tan diferente al de Linux es interesante e invitaría a opinar al respecto.

Me doy cuenta de que, muy a menudo, un dispositivo Nano solo obtendrá su energía del cable USB y esto está bien, pero solo si tiene algún tipo de cargador de arranque en el AVR que sepa cómo manejar estos reinicios esporádicos y evite obtenerlo por sí mismo ( y probablemente el CH340 también) en un estado desconocido y roto.

Resolví esto agregando un límite de 0.1uF entre DTR y Gnd. Todo está funcionando bien. Con alimentación USB, externa e incluso con ambas juntas, el comportamiento de reinicio del controlador es bastante normal. Arranca sin problemas y el restablecimiento de DTR funciona desde el software.

Si todavía recibe reinicios aleatorios y sospecha que CH340 está jugando algunos trucos debido a la ausencia de cualquier señal en USB D+ y D-, o cualquier ráfaga durante la enumeración, etc., antes de condenar al 340 inocente, primero busque otras causas de reinicio. Verifique los reinicios de WDT en su código y también verifique si los reguladores de 5V/3.3V no se están cocinando. La placa china no tiene protección contra el drenaje de energía y simplemente apaga el regulador de voltaje a altas temperaturas.

Después de una inspección exhaustiva de uno de mis productos comerciales (sí, tengo que usar el clon para reducir el costo), se redujo a un regulador de 5V. A alta temperatura, simplemente se apaga a alta velocidad, creando picos. A diferencia del 7805 convencional que comienza a reducir Vcc de manera menos exponencial a altas temperaturas. Incluso a veces bloquea el programa si el límite adicional entre Gnd y Vcc no es suficiente debido a estos picos. Así que llegué a la conclusión de que un límite de 0.1uF en DTR a GND, un límite de 220uF en 5Vcc del controlador a Gnd y un 7805 para encender todo lo demás (tarjeta SD, LCD, cámara, etc.) resuelve todo. No olvide el disipador de calor y las tapas necesarias junto al 7805; de lo contrario, también comenzará a calentarse.