Conflictos entre drivers CH340 y FTDI en Windows 11: guía completa

Cuando actualizamos a Windows 11, muchos aficionados a la electrónica se topan con un problema que no esperaban: los drivers USB serie de chips como CH340 y FTDI empiezan a dar guerra, sobre todo en placas Arduino clon o dispositivos con conversores USB‑serie baratos. De repente, lo que funcionaba perfectamente en Windows 10 deja de detectarse, aparece como “USB desconocido” o simplemente desaparece de la lista de puertos COM.

En este artículo vamos a desgranar, con calma pero al detalle, qué está pasando con los controladores CH340 y FTDI en Windows 11, por qué aparecen conflictos y qué se puede hacer para recuperar la comunicación serie. Veremos mensajes raros como “controlador preinstalado”, errores de firma, el histórico “caballo de Troya” de FTDI que dejaba chips K.O., y cómo desinstalar y reinstalar drivers de forma limpia para que tu Arduino, impresora 3D o cualquier dispositivo USB‑serie vuelva a la vida.

Por qué se rompen los drivers CH340 y FTDI al pasar a Windows 11

Muchos usuarios actualizan de Windows 10 a Windows 11 y descubren que sus placas Arduino clon (tipo “Hero”, Nano, etc.) que usan el chip CH340 dejan de crear un puerto COM funcional. El sistema fuerza el uso del controlador genérico USB de Microsoft y, aunque el dispositivo se vea en el Administrador de dispositivos, no hay forma de comunicarse con la placa.

En estos casos, al intentar actualizar manualmente el controlador, Windows muestra un aviso indicando que el driver ya estaba “preinstalado” y no ofrece una instalación completa ni la opción de sustituir el controlador activo. Esto genera bastante confusión, porque parece que el sistema reconoce el paquete del fabricante, pero sigue prefiriendo el driver estándar de Microsoft que, para muchas placas clon con CH340, simplemente no funciona bien.

Cuando el usuario decide desinstalar el controlador CH34x para empezar de cero, se encuentra con otro obstáculo: el desinstalador indica que no encuentra el controlador o que no hay nada que eliminar. A efectos prácticos, el driver está “a medio camino”: Windows sabe que existe, lo marca como preinstalado, pero no permite ni quitarlo de forma sencilla ni activarlo correctamente sobre el dispositivo USB.

Todo esto apunta a un comportamiento bastante agresivo de Windows 11 con los controladores USB‑serie: prioriza drivers firmados y empaquetados en Windows Update, y en algunos casos ignora o bloquea el uso de paquetes de terceros, incluso aunque sean oficiales del fabricante del chip. En placas Arduino originales, que usan chips oficiales y firmados (por ejemplo, ATmega16U2 o FTDI genuino en modelos antiguos), el mismo cable y el mismo puerto USB funcionan sin problemas, pero con clones CH340 la historia cambia.

Problemas típicos al instalar drivers CH340 y FTDI en Windows 11

Si estás empezando con Arduino y tu portátil con Windows 11 no detecta tu placa como puerto COM, es fácil caer en un bucle de instalaciones fallidas. Uno de los síntomas más habituales es que el Administrador de dispositivos muestra el dispositivo como “USB desconocido” o similar, sin asignar puerto serie virtual, aunque hayas seguido tutoriales al pie de la letra.

Tras ejecutar el instalador del fabricante del chip (por ejemplo, el paquete para CH340G), al finalizar la instalación aparece un mensaje poco claro: Windows informa de que el controlador ha sido “preinstalado” pero no se ha completado una instalación normal. Es un texto que no suele salir en los tutoriales clásicos y deja al usuario con la duda de si debe hacer algo más o si el driver está realmente operativo.

Algunos manuales recomiendan desinstalar el driver y volver a instalarlo. Sin embargo, cuando se intenta la desinstalación, Windows responde que no encuentra el controlador o que no hay nada que quitar. Es decir, el sistema considera que el driver nunca llegó a instalarse de forma completa, aunque sí lo tenga fichado como preinstalado en su base de datos de controladores.

Este comportamiento se repite incluso cuando se prueban varios equipos distintos, por ejemplo un portátil con Windows 11 y un sobremesa con Windows 10. En ambos casos, el resultado es idéntico: el dispositivo sigue figurando como USB desconocido, no aparece puerto COM y los intentos de reinstalación del controlador acaban en el mismo bucle de mensajes.

Ni siquiera instalar todas las últimas actualizaciones de Windows, incluyendo las opcionales, suele cambiar la situación. Si el sistema decide que el dispositivo debe usar el driver genérico o uno que él considera “más seguro”, es muy probable que ignore tu intento de forzar el uso del driver del fabricante, especialmente si ese driver no está firmado de la forma en que Microsoft exige en Windows 11.

El caso FTDI: drivers maliciosos, chips clon y “caballo de Troya”

Los problemas con FTDI vienen de lejos y ayudan a entender por qué hoy se usan tanto los chips CH340 como alternativa en muchas placas económicas. Hace años, FTDI lanzó unas versiones de sus drivers para Windows que incluían un comportamiento extremadamente agresivo: si detectaban un chip supuestamente falso o no autorizado (clon FTDI), escribían en su memoria EEPROM valores inválidos, dejándolo sin identificación USB válida.

El impacto fue enorme. Desde aproximadamente septiembre de aquel año, empezaron a caer dispositivos como moscas: Arduinos Nano, programadores, cables conversores y todo tipo de aparatos que integraban chips clon FTDI. Usuarios que actualizaban tranquilamente sus drivers a través de Windows Update veían cómo, al volver a conectar su dispositivo, Windows ya no lo reconocía y era imposible abrir un puerto serie.

No se trataba de un fallo accidental: los drivers contenían deliberadamente un “caballo de Troya” que modificaba el idVendor y el idProduct de la EEPROM del chip. Los valores correctos para un FTDI reconocido en Windows eran algo como:

• idVendor: 0x0403
• idProduct: 0x6001

Tras la acción de los drivers maliciosos, muchos de esos chips terminaban con el mismo idVendor (0x0403) pero un idProduct 0x0000 que no se correspondía con ningún dispositivo FTDI legítimo. A efectos prácticos, el chip quedaba “borrado” a nivel de identificación USB, y Windows ya no sabía qué hacer con él.

La versión conflictiva de los controladores FTDI se situaba alrededor de la 2.12.0.0, mientras que las versiones anteriores, como la 2.10.0.0 y anteriores, no incluían ese comportamiento destructivo. Durante un tiempo, Windows Update repartió masivamente ese driver agresivo, dejando millones de dispositivos potencialmente inutilizados sin que el usuario fuese consciente de lo que estaba ocurriendo.

FTDI defendió su postura argumentando que era una medida contra la falsificación de sus chips, pero la realidad es que el gran perjudicado fue el usuario final, que no tenía forma de saber si el conversor USB‑serie de su dispositivo era original o clon. Distribuidores, fabricantes de placas y diseñadores también se vieron seriamente afectados, ya que ellos tampoco tenían control sobre la autenticidad del chip que les llegaba de fábrica.

Diagnóstico de un chip FTDI dañado por drivers maliciosos

Cuando un FTDI clon había sido “marcado” por aquellos controladores, el síntoma más evidente era que Windows dejaba de reconocer el dispositivo y no ofrecía puerto COM. Sin embargo, a diferencia de un fallo de hardware, el chip seguía físicamente intacto: lo que se había corrompido era su identificación en la EEPROM.

Para comprobarlo se podía utilizar una herramienta como USBView, un ejecutable que muestra en detalle todos los dispositivos conectados a los puertos USB y sus descriptores. Al conectar el dispositivo sospechoso, se podían leer sus valores de identificación y comparar:

• Valores correctos para un FTDI genuino: idVendor 0x0403, idProduct 0x6001.
• Valores tras el borrado malicioso: idVendor 0x0403, idProduct 0x0000.

Si al inspeccionar el dispositivo veías ese idProduct 0x0000, estaba claro que el chip había sido “borrado” por el driver y que Windows ya no lo trataría como un conversor USB‑serie estándar

.

En estas condiciones, el usuario no tenía un problema de hardware roto, sino de configuración interna del chip. La buena noticia es que, con las herramientas adecuadas, era posible reescribir esos datos de la EEPROM y devolver al chip su identidad correcta, siempre que el propio FTDI no hubiese bloqueado por completo la posibilidad de reprogramar la memoria.

Durante un tiempo, FTDI retiró de sus drivers el caballo de Troya (manteniendo la numeración 2.12.0.0, pero supuestamente sin borrado de EEPROM), aunque no ofreció ninguna solución oficial para los millones de chips ya afectados. Muchos usuarios y comunidades se sintieron doblemente agraviados: primero por el daño causado, y después por la falta de una herramienta de recuperación simple y oficial.

Cambiar de FTDI a CH340: una alternativa más amigable (pero con trampa en Windows)

Tras el escándalo de FTDI, muchos fabricantes de placas y dispositivos comenzaron a migrar a otros conversores USB‑serie. Uno de los más populares ha sido el chip CH340G y sus variantes, de origen chino y coste muy bajo. Este chip cumple la misma función básica: emular un puerto serie virtual (COM) a través de USB para hablar con microcontroladores, impresoras 3D, etc.

En sistemas GNU/Linux, el soporte para CH340 suele ser excelente: el kernel lo reconoce de serie y no hace falta instalar drivers adicionales. En macOS, en muchos casos funciona con drivers específicos o con módulos ya compatibles. El problema gordo suele aparecer en Windows, donde sí es necesario instalar un controlador específico para que el sistema cree el puerto COM.

El procedimiento, en principio, es muy sencillo: se descarga el paquete oficial del fabricante del chip (o proporcionado por el distribuidor de la placa), se ejecuta el instalador y, al conectar el dispositivo, Windows debería detectarlo como “USB‑Serial CH340” o similar y asignar un COM. El inconveniente es que, con Windows 10 y especialmente con Windows 11, entran en juego las políticas de firma de drivers y la tendencia de Microsoft a imponer su propio stack USB estándar.

En la práctica, muchos usuarios se encuentran con que, a pesar de seguir el proceso de instalación, el sistema se empeña en usar un controlador genérico o un driver de Windows Update, que no siempre se lleva bien con determinados clones o versiones del CH340. De ahí vienen situaciones en las que la misma placa funciona en Linux sin tocar nada, pero en Windows se queda atrapada como “USB desconocido”.

Por ese motivo, algunas comunidades recomiendan directamente evitar productos con FTDI (original o copiado) y optar por chips como CH340, CP2102, etc. Sin embargo, esto no nos libra de los roces con Windows 11, que sigue siendo muy exigente con firmas, catálogos y controladores considerados “seguros”.

Limpiar drivers conflictivos y forzar la instalación correcta

Cuando un dispositivo USB‑serie deja de funcionar, una de las soluciones más efectivas pasa por limpiar por completo los drivers asociados y volver a instalarlos de forma manual. Esto es especialmente importante si sospechas que tu sistema ha tenido versiones problemáticas de FTDI o múltiples intentos fallidos con CH340.

En el caso de FTDI, existen utilidades como CDMuninstallerGUI que permiten borrar los controladores USB‑serie registrados en el sistema en función de sus identificadores. Indicando los datos idVendor 0x0403 e idProduct 0x6001, el programa elimina tanto los drivers como las referencias al dispositivo, de modo que la próxima vez que lo conectes, Windows lo tratará como si fuese la primera vez.

Este tipo de limpieza es útil cuando Windows se ha quedado enganchado a una versión concreta de los drivers (por ejemplo, la 2.12.0.0 problemática) y no quiere actualizar ni retroceder a una versión anterior. Después de pasar la herramienta y reiniciar el equipo, es posible instalar manualmente una versión de driver conocida como segura, como la 2.10.0.0, y hacer que el sistema la acepte para ese dispositivo. Además, en ocasiones es necesario borrar controladores antiguos en DriverStore para evitar que Windows vuelva a restaurar la versión conflictiva.

Para CH340, el enfoque es similar pero sin herramientas específicas de FTDI. A menudo basta con ir al Administrador de dispositivos, localizar el USB desconocido o el adaptador USB‑serie con problema, desinstalar el dispositivo marcando la casilla “Eliminar el software de controlador para este dispositivo”, y después instalar de nuevo el paquete del fabricante antes de reconectar la placa.

Un punto clave en Windows 11 es desactivar, si procede, la instalación automática de controladores a través de Windows Update. Desde “Dispositivos e impresoras”, haciendo clic derecho sobre el icono del PC y entrando en “Configuración de la instalación de dispositivos”, se puede seleccionar una opción que limite o impida que Windows reemplace tus drivers manuales por otros “recomendados” desde Internet, lo que reduce el riesgo de que el sistema te cambie el controlador en cuanto conectes el USB.

Rehabilitar un chip FTDI borrado: recuperación de la EEPROM

Si tu situación es más extrema y sospechas que tu chip FTDI clon ha sido “borrado” por los antiguos drivers, todavía puedes intentar resucitarlo. El proceso es algo avanzado, pero permite recuperar idVendor e idProduct correctos y volver a usar el dispositivo con normalidad, al menos a nivel de comunicación USB‑serie.

El primer paso consiste en conseguir que el chip, aunque tenga idProduct 0x0000, sea reconocido por Windows como un dispositivo FTDI al que se le puedan aplicar drivers. Para ello, una técnica clásica es modificar los archivos INF de una versión de driver conocida (por ejemplo, la 2.10.0.0), añadiendo a la lista de dispositivos soportados la combinación idVendor 0x0403, idProduct 0x0000.

Concretamente, habría que editar ftdibus.inf y ftdiport.inf, añadir las entradas que identifiquen al dispositivo con ese PID “borrado”, y luego instalar el driver de forma manual desde el Administrador de dispositivos, apuntando a la carpeta donde se encuentran esos archivos modificados. Windows advertirá de que los drivers no están firmados o que el archivo INF ha sido alterado, pero si aceptas la instalación, el sistema pasará a ver el dispositivo como un conversor USB‑serie FTDI funcional.

Una vez que el chip vuelve a ser operativo a ojos de Windows, el siguiente paso es reprogramar su EEPROM con los valores correctos. Para eso se utiliza la aplicación FT_Prog, la herramienta oficial de FTDI para configurar sus chips. Tras ejecutarla, se escanea el bus USB (icono de la lupa), se detecta el dispositivo y se cargan sus parámetros actuales.

En el apartado “USB Device Descriptor”, se puede seleccionar la opción adecuada para “Custom PID” o elegir directamente “FTDI Default” para que la herramienta rellene los identificadores por defecto (por ejemplo, Product ID 0x6001). A continuación, se hace clic en el icono del rayo y se pulsa “Program” para escribir los cambios en la EEPROM del chip.

Al desconectar y volver a conectar el USB, si todo ha ido bien, Windows reconocerá el dispositivo otra vez como “USB Serial Port” con un ID coherente, y se podrá usar con los drivers oficiales sin necesidad de seguir trucos adicionales. Puedes verificar los nuevos valores con USBView o directamente en el Administrador de dispositivos, comprobando que aparece bajo la categoría de puertos COM.

Errores de firma, hashes y compatibilidad x64/x86

Otro tipo de problema que se ve con frecuencia al instalar drivers FTDI o CH340 en versiones modernas de Windows son los mensajes de error relacionados con la certificados y firmas de drivers y el hash del archivo. Estos errores suelen aparecer cuando intentas forzar la instalación de un driver antiguo o procedente de una fuente no totalmente alineada con los requisitos de seguridad de Microsoft.

Un caso típico es el siguiente: intentas apuntar Windows al archivo arduino.inf (o al INF genérico del fabricante) desde la carpeta “drivers” de tu IDE de Arduino, y Windows responde con un aviso indicando que la carpeta no contiene ningún controlador de software compatible con el dispositivo. Además, añade que, si contiene un controlador, compruebes que esté diseñado para sistemas basados en x64 o x86 según corresponda.

Esto suele significar que el INF no está preparado para tu versión de Windows o tu arquitectura (32/64 bits), o simplemente que el dispositivo conectado no coincide con ninguno de los identificadores listados dentro del archivo. En ese caso, aunque el INF esté bien para otros modelos, Windows lo rechaza porque no ve un emparejamiento claro con el hardware presente.

Otro mensaje muy común cuando se intenta instalar controladores FTDI desde una carpeta como “ftdi” es algo del estilo: “El hash para el archivo no está presente en el archivo de catálogo especificado. Es posible que el archivo esté dañado o haya sido manipulado”. Traducido: el sistema no confía en el archivo porque su firma no concuerda con el catálogo criptográfico o directamente no existe, y por defecto bloquea la instalación.

Este tipo de bloqueos tiene relación directa con las políticas de seguridad de Microsoft para controladores de kernel. En Windows 10 y, más aún, en Windows 11, se exigen firmas válidas y verificables para permitir la carga de muchos drivers. Si trabajas con hardware antiguo o con archivos INF modificados a mano, es relativamente fácil toparse con este muro.

En algunos casos avanzados, los usuarios optan por arrancar Windows con la verificación de firmas de controladores deshabilitada (modo de prueba o configuraciones especiales de arranque). No obstante, para la mayoría de usuarios domésticos esto no es recomendable, y es mejor buscar una versión firmada y actualizada del controlador o usar una placa con un chip más compatible de serie.

Consejos prácticos para evitar conflictos entre CH340, FTDI y Windows 11

Más allá de los detalles técnicos, hay una serie de buenas prácticas que ayudan mucho a reducir la probabilidad de conflictos de drivers entre CH340, FTDI y Windows 11, especialmente si trabajas con varias placas y dispositivos a la vez.

En primer lugar, es importante identificar qué chip lleva realmente tu placa o tu adaptador USB‑serie. Muchos clones de Arduino UNO, Nano, “Hero” y similares llevan CH340, otros usan FTDI (original o copia), y algunos incluso integran otros conversores como CP210x. Saber qué tienes entre manos te permitirá descargar el driver correcto y evitar instalar paquetes innecesarios.

También resulta útil mantener cierto control sobre las actualizaciones de drivers de Windows. Si tienes un entorno que funciona bien, no es mala idea desactivar la actualización automática de controladores y gestionar tú mismo las nuevas versiones, especialmente en equipos dedicados a impresión 3D, CNC o automatización, donde un fallo en el puerto COM puede dejarte colgado en mitad de un trabajo.

Cuando un dispositivo deja de funcionar de golpe tras una actualización, conviene sospechar de cambios de driver. En ese caso, una estrategia razonable es revisar el historial de actualizaciones de Windows, desinstalar el controlador problemático y reinstalar manualmente la versión que sabes que funcionaba. Esto es aplicable tanto a FTDI como a CH340, y suele devolver la estabilidad al sistema.

Por último, si trabajas con hardware muy económico o con clones de origen dudoso, es recomendable tener a mano herramientas como USBView, FT_Prog o utilidades de desinstalación de drivers. Aunque no son imprescindibles en el día a día, te permiten diagnosticar problemas profundos (como un idProduct corrupto o un conflicto de drivers) y te pueden ahorrar tirar a la basura un dispositivo que aún tiene arreglo. También es útil saber ver todos los drivers instalados para auditar el sistema cuando algo falla.

Lidiar con conflictos entre drivers CH340 y FTDI en Windows 11 se convierte en una mezcla de paciencia, limpieza de controladores y control manual de lo que el sistema instala o deja de instalar. Conociendo el historial de FTDI, las particularidades del CH340 y el celo de Windows 11 con los drivers firmados, es mucho más fácil interpretar los mensajes raros, elegir el controlador adecuado y recuperar la comunicación serie de tus Arduinos, impresoras 3D y demás cacharros sin volverte loco ni renunciar a tu hardware.