LightMessenger : Débogage en profondeur avec Derek

Dans ce billet d'invité, Derek aka Codeallnight fait une plongée en profondeur dans le débogage du LightMessenger. C'est une incursion fascinante et détaillée dans les défis du débogage de matériel, les leçons apprises en cours de route et les conseils pour les mainteneurs de projets open-source.

Si vous avez aimé cet article et que vous souhaitez soutenir Derek, pensez à utiliser le code DEREK à la caisse de Lab401 (ou cliquez simplement sur le lien). Vous obtiendrez 5% de réduction sur le LightMessenger (et d'autres produits Lab401) et vous soutiendrez Derek en même temps !

Vous pouvez également consulter les réseaux sociaux de Derek :

🎬 YouTube : @MrDerekJamison

🎮 Discord : @CodeAllNight

🐱 GitHub : Tutoriels Flipper Zero

Débogage de la carte GPIO Light Messenger Lab401 pour Flipper Zero

J'ai récemment reçu une carte GPIO Light Messenger de Lab401. Bien qu'elle fonctionne généralement bien, j'ai rencontré un problème où les LEDs n'affichaient parfois pas le message programmé, même en la déplaçant à la même vitesse qu'auparavant.

Pensant qu'il s'agissait d'un problème de firmware, j'ai flashé mon Flipper Zero avec le firmware officiel, mais le problème a persisté. Il s'avère que j'étais l'un des premiers utilisateurs du Light Messenger et que j'utilisais la version 1.1 de l'application. Alerte au spoiler : ce problème de rendu a été résolu dans la version 1.2 de l'application Light Messenger.

La version 1.1 avait également très peu de documentation sur le fonctionnement de l'appareil, j'ai donc dû creuser dans le code pour savoir quelles étaient les broches utilisées. Cependant, le code était bien structuré et modulaire, ce qui le rendait relativement facile à parcourir.

Mes antécédents et mon approche

Au cours des deux dernières années, j'ai créé des tutoriels Flipper Zero sur YouTube et j'ai écrit des exemples d'applications et un wiki pour l'appareil. Dans cet article de blog, je vais partager mon parcours de débogage, y compris quelques détours inutiles qui n'ont pas directement contribué à résoudre le problème, mais qui ont fourni des informations précieuses.

Étape 1 : Comprendre le matériel

J'ai commencé par lire la fiche technique de l'accéléromètre LIS2DH12, qui m'a aidé à comprendre comment les axes X, Y et Z étaient orientés lorsque le Light Messenger était connecté au Flipper Zero. La plupart des mouvements se produisent le long de l'axe Z lorsque l'on secoue l'appareil. Je n'ai pas tenu compte des détails de synchronisation SPI et I2C et je me suis concentré sur la compréhension des registres pertinents, qui permettent de contrôler et d'obtenir des données de l'appareil.

Étape 2 : Mise en place des outils de débogage

J'ai essayé d'utiliser mon débogueur BlackMagic en connectant des fils de liaison DuPont entre toutes les broches du Light Messenger et mon Flipper Zero (fixé à l'aide d'une planche à pain). J'ai ensuite connecté mon module Wi-Fi Flipper Zero (flashé avec le firmware BlackMagic) aux broches 9-12 du Flipper Zero.

Cependant, j'ai découvert que SWC (Flipper Pin 10) était connecté à la broche d'interruption 2 du LIS2DH12, ce qui empêchait le débogueur VS Code de se connecter ! Pour contourner ce problème, j'ai modifié le fichier app_params.h pour utiliser PB2 (Flipper Pin 6) pour l'interruption 2 à la place. J'ai également dû déplacer le fil venant de la broche 10 du Light Messenger pour le connecter à la broche 6 du Flipper Zero. Cela a permis au débogueur de se connecter, mais le problème est toujours présent.

#define LGHTMSG_INT2PIN &gpio_ext_pb2 // Broche d'en-tête 6 = INT2

Conseil pour les développeurs de matériel : Evitez d'utiliser les broches 10 & 12 du Flipper (SWC, SIO) si vous voulez pouvoir connecter le débogueur BlackMagic plus tard.

Etape 3 : Ajuster les valeurs de seuil

Après avoir lu le fichier app_params.h, j'ai constaté que les seuils d'interruption étaient fixés à 60, ce qui détermine la force g requise pour la détection de mouvement. J'ai abaissé les valeurs à 30, réduisant ainsi la force nécessaire pour un événement.

Bien que cet ajustement ait légèrement affecté la précision des glissements gauche/droite, il a permis d'exclure les problèmes mécaniques. Cependant, le problème persistant, je savais qu'il n'était probablement pas dû à un problème de connexion physique.

Étape 4 : Ajout de journaux de débogage

J'ai essayé d'utiliser le CLI (log debug) pour capturer les événements, mais curieusement, le problème semblait disparaître dès que la journalisation était activée. J'ai pensé que cela aurait pu modifier le timing juste assez pour masquer le problème.

Puisque je ne pouvais pas compter sur la journalisation, j'ai décidé de déboguer en utilisant des signaux sonores.

Étape 5 : Utilisation du son pour le débogage

J'ai modifié le code pour qu'il émette

• un son de 440 Hz lorsque la direction change dans un sens
• Un son de 660 Hz lorsque la direction est inversée.

Lorsque l'affichage a cessé de fonctionner, les sons ont également cessé d'être joués. Cela signifie que soit notre thread app_acc_worker s'est arrêté, soit nous avions un problème dans notre routine d'interruption, soit le LIS2DH12 ne déclenchait pas d'interruptions lorsque l'appareil se déplaçait.

Pour approfondir la question, j'ai retiré les fils utilisés pour les interruptions du Flipper Zero(broches 4, 6 et l'un des fils GND). J'ai ensuite pris une résistance et l'ai connectée entre GND et la broche 4, mais rien ne s'est passé. En déplaçant la résistance entre GND et la broche 6, j'ai entendu le son. En revenant à la broche 4, j'ai entendu l'autre tonalité. J'étais en train de déclencher manuellement le code d'interruption ; notre thread app_acc_worker traitait toujours les événements et n'avait pas planté.

C'était une excellente nouvelle - cela confirmait que notre code fonctionnait toujours ! Cependant, pour une raison quelconque, le LIS2DH12 ne déclenchait pas les interruptions lorsque nous déplacions le périphérique.

Étape 6 : vérification des valeurs des registres

En me concentrant sur le LIS2DH12, j'ai pensé que l'un des registres était peut-être réinitialisé à une valeur incorrecte. J'ai pensé que, d'une manière ou d'une autre, le registre changeait de valeur au fur et à mesure que nous le secouions. J'ai écrit une routine pour enregistrer les valeurs des registres dans un fichier texte sur la carte SD du Flipper Zero. Certains registres sont marqués comme étant réservés ou pour la température, j'ai donc décidé d'ignorer ces registres.

En comparant les journaux lorsque l'appareil fonctionnait et lorsqu'il tombait en panne, j'ai remarqué que le registre 0x22 avait des valeurs différentes :

• État de fonctionnement : 0xC0
• État d'échec : 0xC8

Voici une copie de la fiche technique qui parle du registre 0x22...

Le premier chiffre (C - ou 1100 en binaire) signifie que I1_CLICK & I1_IA1 ont été activés et que I1_IA2 et I1_ZYXDA ont été désactivés. Le deuxième chiffre (8 - 1000 en binaire) indique que le bit "0(1)" a été mis en place, ce qui, selon la fiche technique, doit être mis à "0" pour un fonctionnement correct.

Étape 7 : Correction du code

J'ai vérifié le fichier drivers\lis2xx12_wrapper.c, qui active explicitement I1_IA1 et désactive I1_IA2 :

lis2dh12_ctrl_reg3_t pin_int1_cfg ; pin_int1_cfg.i1_zyxda = PROPERTY_DISABLE ; pin_int1_cfg.i1_ia1 = PROPERTY_ENABLE ; pin_int1_cfg.i1_ia2 = PROPERTY_DISABLE ; lis2dh12_pin_int1_config_set(stmdev, &pin_int1_cfg) ;

Le fichier drivers\lis2xx12_wrapper.h définit lis2dh12_ctrl_reg3_t comme suit :

typedef struct { uint8_t not_used_01 : 1 ; uint8_t i1_overrun : 1 ; uint8_t i1_wtm : 1 ; uint8_t not_used_02 : 1 ; uint8_t i1_zyxda : 1 ; uint8_t i1_ia2 : 1 ; uint8_t i1_ia1 : 1 ; <<<< uint8_t i1_click : 1 ; } lis2dh12_ctrl_reg3_t ;

Pour résoudre le problème, j'ai explicitement mis not_used_01 et not_used_02 à PROPERTY_DISABLE, et le problème a disparu !

Plus tard, j'ai réalisé que le fait de fixer la valeur initiale de notre structure à 0 aurait permis d'éviter ce problème. En mettant à jour le code comme suit, on obtient le résultat escompté...

lis2dh12_int1_cfg_t int1_cfg = {0} ;

Une amélioration modeste mais significative consisterait à renommer not_used_02 en must_be_cleared pour indiquer que sa valeur est importante. Cela permettrait d'éviter des erreurs similaires dans les développements futurs.

Leçons apprises

• Vérifier les variables non initialisées : Lorsque vous travaillez avec des drapeaux de bits dans des structures, assurez-vous que tous les drapeaux sont explicitement activés.
• Evitez les broches 10 & 12 du Flipper : Si vous avez besoin d'un accès de débogage, ces broches peuvent interférer avec les connexions du débogueur BlackMagic.
• Utilisez d'autres méthodes de débogage : Lorsque l'enregistrement modifie le comportement, utilisez une autre méthode telle qu'un son ou un moteur vibrant.
• Dumping des registres : le dumping des valeurs des registres peut aider à valider que l'appareil est configuré comme prévu.

Ce fut un défi de débogage amusant, et j'espère que cet article aidera d'autres personnes travaillant sur des projets de matériel Flipper Zero!

🎬 YouTube : @MrDerekJamison

🎮 Discord : @CodeAllNight

🐱 GitHub : Tutoriels Flipper Zero