LightMessenger: Approfondimento sul debug con Derek

In questo post ospite, Derek aka Codeallnight fa un'immersione profonda nel debug di LightMessenger. È un'incursione affascinante e dettagliata nelle sfide del debug dell'hardware, nelle lezioni apprese lungo il percorso e nei consigli per i manutentori di progetti open-source.

Se vi piace questo articolo e volete sostenere Derek, utilizzate il codice DEREK alla cassa di Lab401 (o semplicemente fate clic sul link). Otterrete il 5% di sconto su LightMessenger (e su altri prodotti Lab401) e allo stesso tempo sosterrete Derek!

Potete anche dare un'occhiata ai social di Derek:

🎬 YouTube: @MrDerekJamison

🎮 Discordia: @CodeAllNight

🐱 GitHub: Tutorial Flipper Zero

Debug della scheda Lab401 Light Messenger GPIO per Flipper Zero

Recentemente ho ricevuto una scheda Light Messenger GPIO da Lab401. Sebbene in generale abbia funzionato bene, ho riscontrato un problema per cui a volte i LED non visualizzavano il messaggio programmato, anche muovendoli alla stessa velocità di prima.

Pensando che potesse trattarsi di un problema di firmware, ho flashato il mio Flipper Zero con il firmware ufficiale, ma il problema persisteva. Ho scoperto che ero uno dei primi utenti di Light Messenger e che stavo usando la versione 1.1 dell'applicazione. Attenzione: questo problema di rendering è stato risolto nella versione 1.2 dell'applicazione Light Messenger.

La versione 1.1 aveva anche poca documentazione sul funzionamento del dispositivo, quindi ho dovuto scavare nel codice per capire quali pin venivano utilizzati. Tuttavia, il codice era ben strutturato e modulare, il che lo rendeva piuttosto facile da navigare.

Il mio background e il mio approccio

Negli ultimi due anni ho creato tutorial su Flipper Zero su YouTube e ho scritto applicazioni di esempio e un wiki per il dispositivo. In questo post condividerò il mio percorso di debug, comprese alcune deviazioni non necessarie che non hanno contribuito direttamente alla risoluzione del problema, ma che hanno fornito spunti preziosi.

Passo 1: capire l'hardware

Ho iniziato leggendo la scheda tecnica dell'accelerometro LIS2DH12, che mi ha aiutato a capire come erano orientati gli assi X, Y e Z quando Light Messenger era collegato a Flipper Zero. La maggior parte del movimento avviene lungo l'asse Z quando si scuote il dispositivo. Ho tralasciato i dettagli sulla temporizzazione SPI e I2C e mi sono concentrato sulla comprensione dei registri pertinenti, che sono il modo in cui si controllano e si ottengono i dati dal dispositivo.

Passo 2: Impostazione degli strumenti di debug

Ho provato a utilizzare il mio debugger BlackMagic collegando dei ponticelli DuPont tra tutti i pin di Light Messenger e il mio Flipper Zero (fissato con una breadboard). Ho poi collegato il mio modulo Wi-Fi Flipper Zero (flashato con il firmware BlackMagic) ai pin 9-12 del Flipper Zero.

Tuttavia, ho scoperto che SWC (pin 10 del Flipper) era collegato al pin di interrupt 2 del LIS2DH12, impedendo al debugger VS Code di collegarsi! Per ovviare a questo problema, ho modificato il file app_params.h in modo da utilizzare PB2 (pin 6 del Flipper) per l'interrupt 2. Ho dovuto anche spostare il filo che arriva al pin 10 del LIS2DH12. Ho anche dovuto spostare il filo proveniente dal pin 10 di Light Messenger per collegarlo al pin 6 di Flipper Zero. Questo ha permesso al debugger di connettersi, ma il problema si è verificato comunque.

#define LGHTMSG_INT2PIN &gpio_ext_pb2 // Pin 6 della testata = INT2

Suggerimento per gli sviluppatori di hardware: Evitare di utilizzare i pin 10 e 12 di Flipper (SWC, SIO) se si vuole consentire il collegamento del debugger BlackMagic in un secondo momento.

Passo 3: Regolazione dei valori di soglia

Dopo aver letto il file app_params.h, ho scoperto che le soglie di interrupt erano impostate a 60, che determina la forza g necessaria per il rilevamento del movimento. Ho abbassato i valori a 30, riducendo la forza necessaria per un evento.

Sebbene questa regolazione abbia influito leggermente sull'accuratezza delle strisciate a destra e a sinistra, ha contribuito a escludere problemi meccanici. Tuttavia, il problema persisteva, quindi sapevo che probabilmente non era causato da un problema di connessione fisica.

Passo 4: aggiungere i log di debug

Ho tentato di utilizzare la CLI (log debug) per catturare gli eventi, ma stranamente il problema sembrava scomparire ogni volta che si attivava il log. Sospettavo che questo potesse aver modificato i tempi quanto bastava per mascherare il problema.

Poiché non potevo fare affidamento sulla registrazione, ho deciso di eseguire il debug utilizzando i segnali sonori.

Passo 5: usare il suono per il debug

Ho modificato il codice per riprodurre:

• Un tono a 440 Hz quando la direzione cambiava da una parte all'altra
• Un tono a 660 Hz quando la direzione cambiava nell'altro senso.

Quando il display smetteva di funzionare, anche i toni smettevano di essere riprodotti. Questo significa che il nostro thread app_acc_worker si è fermato, oppure che c'era un problema nella nostra routine di interrupt, oppure che il LIS2DH12 non attivava gli interrupt quando il dispositivo si muoveva.

Per indagare ulteriormente, ho rimosso i fili utilizzati per gli interrupt da Flipper Zero(pin 4, 6 e uno dei fili GND). Ho quindi preso un resistore e l'ho collegato tra GND e il pin 4, ma non è successo nulla. Spostando il resistore a GND e al pin 6, ho sentito il tono. Tornando al pin 4, ho sentito l'altro tono. Stavo attivando manualmente il codice di interruzione; il nostro thread app_acc_worker stava ancora elaborando gli eventi e non si era bloccato.

Questa era un'ottima notizia: confermava che il nostro codice era ancora in esecuzione! Tuttavia, per qualche motivo, il LIS2DH12 non attivava gli interrupt quando spostavamo il dispositivo.

Passo 6: Controllo dei valori dei registri

Concentrandomi sull'LIS2DH12, ho pensato che forse uno dei registri era stato reimpostato su un valore errato. Ho pensato che in qualche modo il registro stesse cambiando valore mentre lo scuotevamo. Ho scritto una routine per registrare i valori dei registri in un file di testo sulla scheda SD di Flipper Zero. Alcuni dei registri sono contrassegnati come riservati o per la temperatura, quindi ho deciso di ignorarli.

Confrontando i registri di quando il dispositivo funzionava e di quando non funzionava, ho notato che il registro 0x22 aveva valori diversi:

• Stato di lavoro: 0xC0
• Stato di guasto: 0xC8

Ecco una copia del datasheet che parla del registro 0x22...

La prima cifra (C - o 1100 in binario) significa che I1_CLICK e I1_IA1 erano abilitati e I1_IA2 e I1_ZYXDA erano disabilitati. La seconda cifra (8 - 1000 in binario) indica che è stato impostato il bit "0(1)" che, secondo la scheda tecnica, deve essere impostato su '0' per un funzionamento corretto.

Passo 7: correzione del codice

Ho controllato il file drivers\lis2xx12_wrapper.c, che abilitava esplicitamente I1_IA1 e disabilitava 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);

Il file drivers\lis2xx12_wrapper.h definisce lis2dh12_ctrl_reg3_t come:

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;

Per risolvere il problema, ho impostato esplicitamente not_used_01 e not_used_02 su PROPERTY_DISABLE e il problema è scomparso!

In seguito, mi sono reso conto che impostare il valore iniziale della nostra struct a 0 avrebbe evitato il problema. Aggiornando il codice come segue si ottiene il risultato desiderato...

lis2dh12_int1_cfg_t int1_cfg = {0};

Un piccolo ma significativo miglioramento sarebbe quello di rinominare not_used_02 in must_be_cleared per indicare che il suo valore è importante. Questo eviterebbe errori simili nello sviluppo futuro.

Lezioni imparate

• Controllare le variabili non inizializzate: Quando si lavora con i flag di bit nelle strutture, assicurarsi che tutti i flag siano impostati esplicitamente.
• Evitare i pin 10 e 12 del Flipper: se è necessario accedere al debug, questi pin possono interferire con le connessioni del debugger BlackMagic.
• Utilizzare metodi di debug alternativi: Quando la registrazione altera il comportamento, utilizzare un altro metodo, come il suono o il motore a vibrazione.
• Dumping dei registri: il dumping dei valori dei registri può aiutare a verificare che il dispositivo sia configurato come previsto.

È stata una sfida divertente per il debug e spero che questo articolo sia d'aiuto ad altri che lavorano su progetti hardware di Flipper Zero!

🎬 YouTube: @MrDerekJamison

🎮 Discord: @CodeAllNight

🐱 GitHub: Tutorial Flipper Zero