El ESP32 no sube el programa: causas y cómo destrabarlo

Parte por el cable, porque es la causa más común y la más barata de descartar: muchos cables USB traen sólo los dos hilos de alimentación y ningún par de datos. Cargan un teléfono perfecto y no sirven para programar nada, y por fuera se ven iguales. Prueba con el de un disco externo, que ese sí lleva datos.

Si el cable lleva datos, lo que sigue depende de qué placa tengas, y acá hay una diferencia que confunde a mucha gente.

Las placas ESP32 clásicas —las alargadas de treinta y tantos pines— suelen llevar un chip aparte que traduce USB a serie: un CH340 o un CP2102. Ese chip es el que tu computador tiene que reconocer, y para eso necesita el driver del fabricante. Sin driver no aparece ningún puerto por más que la placa esté enchufada y con corriente.

La SuperMini no lleva ese chip. Habla USB directo desde el mismo silicio, por un periférico que Espressif llama USB Serial/JTAG: el D+ sale por GPIO19 y el D− por GPIO18. Por eso no necesita driver — el sistema la ve como un puerto serie USB estándar y aparece sola.

Ojo con la conclusión fácil, porque acá es donde alguien se va sin arreglar su problema: que el chip sepa hablar USB no significa que toda placa con un C3 lo aproveche. La ESP32-C3-DevKitM-1, de la propia Espressif, trae un puerto micro-USB con un conversor USB-serie detrás, y esa sí pide driver.

¿Y cómo sabes cuál de las dos tienes? Si no te aparece ningún puerto, la respuesta corta es que da lo mismo: instala el driver del CH340 y el del CP2102, y vuelve a mirar. En una placa de USB nativo no estorban, y en una con conversor es exactamente el paso que te faltaba. Lo que no sirve para decidirlo es mirarle los chips a la placa: en placas de este tipo suele haber más de un integrado chico además del módulo, y ninguno viene rotulado para que lo adivine alguien que recién parte.

Cuando el puerto ya aparezca, el nombre sí te dice cuál es. En Linux es limpio, y lo documenta Espressif: el USB nativo sale como /dev/ttyACM… y un conversor sale como /dev/ttyUSB…. En Windows los dos salen como COM y el nombre no distingue nada. En macOS los dos empiezan con /dev/cu., y ahí Espressif no se compromete con más que eso para el USB nativo los ejemplos de conversores que publica sí traen la marca en el nombre —cu.usbserial-… o cu.SLAB_USBtoUART—, pero eso es indicio nuestro y no una regla suya.

El mensaje completo, tal como sale:

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

Dos variantes de lo mismo. Si le declaraste al IDE una placa C3, en el medio dirá «Failed to connect to ESP32-C3». Y si tienes esptool 4 o más nuevo —que es lo que traen las versiones recientes del soporte de ESP32 para Arduino—, la misma falla se escribe «Failed to connect to ESP32-C3: No serial data received.». Es el mismo problema con otra redacción.

Qué está diciendo: esptool reseteó la placa, mandó el saludo de sincronización y no le contestó nadie. El puerto existe, la placa está encendida, pero lo que hay al otro lado no es el bootloader esperando un programa — es tu programa anterior corriendo tranquilo.

Por qué pasa: para poder recibir un programa nuevo, el chip tiene que arrancar en modo de descarga en vez de arrancar lo que ya tiene en la flash. Eso se decide en el instante del reset, mirando el nivel de unos pines llamados de strapping, y después ya no se puede cambiar: el chip los lee una vez, se los guarda en un latch y los libera para que los uses como pines normales.

El mensaje sale así, muchas veces cortado por la mitad:

Brownout detector was triggered

No es un error de tu código. Es el chip avisando que el voltaje de alimentación se le fue abajo de un umbral y que por eso se va a resetear, antes de hacer algo impredecible con la memoria a medio escribir. ESP-IDF trae el detector encendido por defecto y en su nivel más bajo, unos 2,51 V sobre el riel de 3,3 V imprime la línea y reinicia.

Que salga cortado no es culpa de tu monitor: la documentación de Espressif advierte que si el voltaje se cae rápido, alcanza a salir sólo parte del mensaje. Si ves «Brownout detect» y nada más, es esto igual.

Caracteres raros, rombos con signo de pregunta, líneas cortadas a la mitad. Casi siempre son los baudios: el monitor y el programa tienen que estar en el mismo número, y si no lo están el monitor lee los bits en el momento equivocado. La pista de que es esto y no un cable malo es que la basura sea estable —los mismos símbolos raros cada vez— y no ruido distinto en cada arranque.

Pon el monitor en el número que dice el Serial.begin() de tu programa. Si dice Serial.begin(115200), el monitor va en 115200.

Hay un caso que confunde, y es el arranque. La ROM del ESP32-C3 imprime su log a 115200 por defecto, y esa velocidad no la cambia tu Serial.begin(): son dos emisores distintos por el mismo cable. Así que si tu programa corre a otra velocidad vas a ver siempre una de las dos partes ilegible, las primeras líneas o el resto. No está fallando nada, y 115200 es el número que deja legibles las dos.

Son dos causas distintas y se distinguen leyendo el log.

Si el reinicio viene acompañado de «Brownout detector was triggered», es alimentación: ándate a esa sección.

Si no aparece ese mensaje, pero la placa arranca en un modo que no es el tuyo o simplemente no corre el programa, mira qué tienes conectado a los pines de strapping. En el ESP32-C3 son GPIO2, GPIO8 y GPIO9, y no son pines especiales todo el tiempo: el chip los lee en el instante del reset y después quedan libres como cualquier otro. El problema es ese instante.

Un pulsador, un sensor con la salida en bajo al partir, la resistencia de pull-down que trae un módulo: cualquier cosa que deje GPIO9 en bajo mientras el chip resetea lo manda al bootloader en vez de a tu programa, y desde afuera eso se ve como «no arranca». Y GPIO8 en bajo junto con GPIO9 en bajo es la combinación que la documentación de esptool declara inválida.