"CH340" controladores de chip de interfaz serie usb causan problemas de reinicio de AVR en Windows / Linux

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

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

El paquete de baterías no tiene líneas de datos ni concepto de enumeración y, por lo tanto, no se realiza ningún reinicio, lo que permite que el Nano se inicie normalmente y se ejecute correctamente.

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

EnelNanoV3.0,laseñalDTResACacopladaalpindereiniciodelATMega328P.Entonces,porcadabordedecaídaenesosrastros,elchipATMega328Pseestáreiniciando.Poralgunarazón,alrealizarestosreinicios,elNanoseencontrabaenunestadodesconocido

LasoluciónparaaquellosdenosotrosquedeseamosusarunNanoV3.0SINNECESIDADdecompatibilidadconArduinoIDEessimplementedesoldarelpequeñocondensadordemontajeensuperficieconectadoalpin13enelCH340EldispositivoNanoV3.0.Esoestodo.

EstoaúnpermitiráqueWindowsyLinuxsecomuniquenconeldispositivoatravésdelainterfazserialylepermitiráalimentareldispositivodesdealgúnsuministroexternode5VyconectarloaunaPCsinqueNanoserestablezca.

Paranosotros,nuestrosdispositivosahorafuncionanbienconAtmelStudio+JTAGICE3yseiniciancorrectamentesinimportarenquélosconectemos.

Conclusión:PuedeserconvenientequealgunasaplicacioneshaganqueelNanosereiniciesolocuandoloconecteaunaPC,peroparecequeesta"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 y me gustaría invitar a que lo comenten.

Me doy cuenta de que muy a menudo un dispositivo Nano solo recibe su poder del cable USB y esto está bien, pero solo si tienes algún tipo de cargador de arranque en el AVR que sabe cómo manejar estos reinicios esporádicos y evita obtener se auto (y probablemente el CH340 también) en un estado desconocido, roto.

Resolví esto agregando un límite de 0.1uF entre DTR y Gnd. Todo está funcionando bien. En la alimentación USB, en el externo e incluso en ambos juntos, el comportamiento de reinicio del controlador es bastante normal. Arranca sin problemas y el restablecimiento de DTR funciona desde el software.

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

Después de una inspección minuciosa 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 en temperaturas altas. Incluso falla el programa a veces si el límite adicional entre Gnd y Vcc no es suficiente debido a estos picos. Así que he llegado 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 adyacentes a 7805, de lo contrario, también comenzará a calentarse.