LightMessenger: Debugging-Tiefgang mit Derek

In diesem Gastbeitrag befasst sich Derek alias Codeallnight eingehend mit dem Debugging des LightMessenger. Es ist ein faszinierender, detaillierter Streifzug durch die Herausforderungen beim Debuggen von Hardware, Lektionen, die auf dem Weg gelernt wurden, und Tipps für Open-Source-Projektbetreuer.

Wenn Ihnen dieser Artikel gefällt und Sie Derek unterstützen möchten, geben Sie bitte den Code DEREK in der Lab401-Kasse ein (oder klicken Sie einfach auf den Link). Sie erhalten 5% Rabatt auf den LightMessenger (und andere Lab401 Produkte) und unterstützen gleichzeitig Derek!

Du kannst auch Dereks soziale Netzwerke besuchen:

🎬 YouTube: @MrDerekJamison

🎮 Discord: @CodeAllNight

🐱 GitHub: Flipper Zero Tutorials

Fehlersuche auf dem Lab401 Light Messenger GPIO Board für Flipper Zero

Ich habe vor kurzem ein Light Messenger GPIO-Board von Lab401 erhalten. Während es im Allgemeinen gut funktionierte, stieß ich auf ein Problem, bei dem die LEDs manchmal nicht die programmierte Nachricht anzeigten, selbst wenn ich sie mit der gleichen Geschwindigkeit wie zuvor bewegte.

In der Annahme, es könnte sich um ein Firmware-Problem handeln, habe ich meinen Flipper Zero mit der offiziellen Firmware geflasht, aber das Problem blieb bestehen. Es stellte sich heraus, dass ich einer der ersten Nutzer des Light Messenger war und die Version 1.1 der Anwendung verwendete. Spoiler-Alarm: Dieses Rendering-Problem wurde in Version 1.2 der Light Messenger-Anwendung behoben.

Die Version 1.1 enthielt auch sehr wenig Dokumentation über die Funktionsweise des Geräts, so dass ich mich in den Code vertiefen musste, um zu erfahren, welche Pins verwendet wurden. Der Code war jedoch gut strukturiert und modular aufgebaut, so dass er recht einfach zu navigieren war.

Mein Hintergrund und meine Herangehensweise

In den letzten zwei Jahren habe ich Flipper Zero-Tutorials auf YouTube erstellt und Beispielanwendungen und ein Wiki für das Gerät geschrieben. In diesem Blogbeitrag erzähle ich von meinem Weg der Fehlersuche, einschließlich einiger unnötiger Umwege, die nicht direkt zur Lösung des Problems beigetragen haben, aber wertvolle Erkenntnisse lieferten.

Schritt 1: Verstehen der Hardware

Ich begann damit, das Datenblatt des LIS2DH12-Beschleunigungsmessers zu lesen, was mir half zu verstehen, wie die X-, Y- und Z-Achse ausgerichtet sind, wenn der Light Messenger an den Flipper Zero angeschlossen ist. Der größte Teil der Bewegung erfolgt entlang der Z-Achse, wenn das Gerät geschüttelt wird. Ich habe die Details des SPI- und I2C-Timings übersprungen und mich auf das Verständnis der relevanten Register konzentriert, mit denen man das Gerät steuert und Daten von ihm erhält.

Schritt 2: Einrichten von Debugging-Tools

Ich habe versucht, meinen BlackMagic-Debugger zu verwenden, indem ich DuPont-Jumper-Drähte zwischen allen Light Messenger-Pins und meinem Flipper Zero (gesichert mit einem Breadboard) angeschlossen habe. Dann schloss ich mein Flipper Zero Wi-Fi-Modul (mit BlackMagic-Firmware geflasht) an die Pins 9-12 des Flipper Zero an.

Ich stellte jedoch fest, dass SWC (Flipper Pin 10) mit dem Interrupt 2 Pin des LIS2DH12 verbunden war, wodurch der VS Code Debugger nicht angeschlossen werden konnte! Um dies zu umgehen, änderte ich die Datei app_params.h, um stattdessen PB2 (Flipper Pin 6) für Interrupt 2 zu verwenden. Außerdem musste ich den Draht, der von Pin 10 am Light Messenger kommt, an Pin 6 am Flipper Zero anschließen. Dadurch konnte der Debugger eine Verbindung herstellen, aber das Problem trat immer noch auf.

#define LGHTMSG_INT2PIN &gpio_ext_pb2 // Header-Pin 6 = INT2

Tipp für Hardware-Entwickler: Vermeiden Sie die Verwendung der Flipper-Pins 10 & 12 (SWC, SIO), wenn Sie später den Anschluss des BlackMagic-Debuggers ermöglichen wollen.

Schritt 3: Anpassen der Schwellenwerte

Nachdem ich die Datei app_params.h durchgelesen hatte, stellte ich fest, dass die Interrupt-Schwellenwerte auf 60 eingestellt waren, was die für die Bewegungserkennung erforderliche g-Kraft bestimmt. Ich habe die Werte auf 30 gesenkt, um die für ein Ereignis erforderliche Kraft zu verringern.

Diese Anpassung wirkte sich zwar geringfügig auf die Genauigkeit der Links-/Rechtsbewegungen aus, aber es half, mechanische Probleme auszuschließen. Das Problem blieb jedoch bestehen, so dass ich wusste, dass es wahrscheinlich nicht durch ein physisches Verbindungsproblem verursacht wurde.

Schritt 4: Hinzufügen von Debugging-Protokollen

Ich versuchte, mit CLI (Log Debug) Ereignisse zu erfassen, aber seltsamerweise schien das Problem zu verschwinden, sobald die Protokollierung aktiviert wurde. Ich hatte den Verdacht, dass dies das Timing gerade so weit verändert hatte, dass das Problem überdeckt wurde.

Da ich mich nicht auf die Protokollierung verlassen konnte, entschied ich mich für eine Fehlersuche mit Hilfe von Tonaufnahmen.

Schritt 5: Verwendung von Ton zur Fehlersuche

Ich änderte den Code, um ihn abzuspielen:

• einen 440-Hz-Ton, wenn die Richtung in eine Richtung wechselte
• einen 660-Hz-Ton, wenn die Richtung gewechselt wurde

Wenn die Anzeige nicht mehr funktionierte, hörten auch die Töne auf zu spielen. Das bedeutete, dass entweder unser app_acc_worker-Thread gestoppt wurde, oder dass wir ein Problem in unserer Interrupt-Routine hatten, oder dass der LIS2DH12 keine Interrupts auslöste, wenn sich das Gerät bewegte.

Um das weiter zu untersuchen, habe ich die Drähte, die für Interrupts verwendet werden, vom Flipper Zero entfernt(Pins 4, 6 und einen der GND-Drähte). Dann nahm ich einen Widerstand und schloss ihn zwischen GND und Pin 4 an, aber es passierte nichts. Als ich den Widerstand an GND und Pin 6 anschloss, hörte ich den Ton. Zurück zu Pin 4 und ich hörte den anderen Ton. Ich löste den Interrupt-Code manuell aus; unser app_acc_worker-Thread verarbeitete immer noch Ereignisse und war nicht abgestürzt.

Das war eine gute Nachricht - sie bestätigte, dass unser Code noch lief! Aus irgendeinem Grund löste der LIS2DH12 jedoch die Interrupts nicht aus, als wir das Gerät verschoben.

Schritt 6: Überprüfen der Registerwerte

Ich konzentrierte mich auf den LIS2DH12 und dachte, dass vielleicht eines der Register auf einen falschen Wert zurückgesetzt wurde. Ich dachte, dass sich der Wert des Registers beim Schütteln irgendwie verändert. Ich schrieb eine Routine, um die Registerwerte in einer Textdatei auf der SD-Karte des Flipper Zero zu speichern. Einige der Register sind als reserviert oder für die Temperatur gekennzeichnet, so dass ich beschloss, diese Register zu überspringen.

Beim Vergleich von Protokollen aus der Zeit, in der das Gerät funktionierte, und aus der Zeit, in der es ausfiel, fiel mir auf, dass das Register 0x22 unterschiedliche Werte aufwies:

• Arbeitszustand: 0xC0
• Fehlerhafter Zustand: 0xC8

Hier ist eine Kopie des Datenblatts, das sich mit dem Register 0x22 befasst...

Die erste Ziffer (C - oder 1100 in binärer Form) bedeutet, dass I1_CLICK & I1_IA1 aktiviert und I1_IA2 und I1_ZYXDA deaktiviert waren. Die zweite Ziffer (8 - 1000 in binärer Form) zeigt an, dass das "0(1)"-Bit gesetzt wurde, das laut Datenblatt für einen korrekten Betrieb auf "0" gesetzt werden muss.

Schritt 7: Behebung des Codes

Ich überprüfte drivers\lis2xx12_wrapper.c, die explizit I1_IA1 aktivierte und I1_IA2 deaktivierte:

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);

Die Datei drivers\lis2xx12_wrapper.h definiert lis2dh12_ctrl_reg3_t als:

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;

Um das Problem zu beheben, setzte ich not_used_01 und not_used_02 explizit auf PROPERTY_DISABLE, und das Problem verschwand!

Später wurde mir klar, dass das Setzen des Anfangswertes unserer Struktur auf 0 dieses Problem von vornherein verhindert hätte. Eine Aktualisierung des Codes auf den folgenden Wert bringt das gewünschte Ergebnis...

lis2dh12_int1_cfg_t int1_cfg = {0};

Eine kleine, aber sinnvolle Verbesserung wäre es, not_used_02 in must_be_cleared umzubenennen, um darauf hinzuweisen, dass sein Wert wichtig ist. Dies würde ähnliche Fehler bei zukünftigen Entwicklungen verhindern.

Gelernte Lektionen

• Überprüfen Sie nicht initialisierte Variablen: Wenn Sie mit Bit-Flags in Strukturen arbeiten, stellen Sie sicher, dass alle Flags explizit gesetzt sind.
• Vermeiden Sie die Flipper-Pins 10 & 12: Wenn Sie Debugging-Zugriff benötigen, können diese Pins die BlackMagic-Debugger-Verbindungen stören.
• Verwenden Sie alternative Debugging-Methoden: Wenn die Protokollierung das Verhalten verändert, verwenden Sie eine andere Methode, z. B. einen Ton- oder Vibrationsmotor.
• Dumping von Registern: Ein Dumping der Registerwerte kann helfen zu überprüfen, ob das Gerät wie erwartet konfiguriert ist.

Dies war eine unterhaltsame Debugging-Herausforderung, und ich hoffe, dieser Bericht hilft anderen, die an Flipper Zero-Hardwareprojekten arbeiten!

🎬 YouTube: @MrDerekJamison

🎮 Discord: @CodeAllNight

🐱 GitHub: Flipper Zero Tutorials