LightMessenger : Profundización en depuración con Derek

En este artículo, Derek aka Codeallnight profundiza en la depuración del LightMessenger. Es una incursión fascinante y detallada en los retos de la depuración de hardware, las lecciones aprendidas en el camino y consejos para los mantenedores de proyectos de código abierto.

Si te gusta este artículo, y quieres apoyar a Derek, por favor considera usar el código DEREK en el Lab401 Checkout (o simplemente haz clic en el enlace). Obtendrás un 5% de descuento en el LightMessenger (y otros productos Lab401) ¡y apoyarás a Derek al mismo tiempo!

También puedes visitar las redes sociales de Derek:

🎬 YouTube: @MrDerekJamison

🎮 Discord: @CodeAllNight

🐱 GitHub: Tutoriales Flipper Zero

Cómo depurar la placa GPIO Light Messenger de Lab401 para Flipper Zero

Recientemente recibí una placa Light Messenger GPIO de Lab401. Aunque en general funcionaba bien, me encontré con un problema en el que los LEDs a veces no mostraban el mensaje programado, incluso cuando se movía a la misma velocidad que antes.

Pensando que podría ser un problema de firmware, actualicé mi Flipper Zero con el firmware oficial, pero el problema persistía. Resulta que fui uno de los primeros usuarios del Light Messenger y estaba utilizando la versión 1.1 de la aplicación. Spoiler alert: Este problema de renderizado se ha solucionado en la versión 1.2 de la aplicación Light Messenger.

La versión 1.1 también tenía muy poca documentación sobre cómo funcionaba el dispositivo, así que tuve que escarbar en el código para saber qué pines se utilizaban. Sin embargo, el código estaba bien estructurado y era modular, lo que facilitaba la navegación.

Mis antecedentes y mi enfoque

Durante los dos últimos años, he estado creando tutoriales de Flipper Zero en YouTube y escribiendo aplicaciones de ejemplo y una wiki para el dispositivo. En esta entrada del blog, voy a compartir mi viaje de depuración, incluyendo algunos desvíos innecesarios que no contribuyeron directamente a resolver el problema, pero proporcionaron información valiosa.

Paso 1: Comprender el hardware

Empecé leyendo la hoja de datos del acelerómetro LIS2DH12, que me ayudó a entender cómo estaban orientados los ejes X, Y y Z cuando la Light Messenger estaba conectada a la Flipper Zero. La mayor parte del movimiento se produce a lo largo del eje Z cuando se agita el dispositivo. Me salté los detalles de sincronización SPI e I2C y me centré en entender los registros relevantes, que es como controlas y obtienes datos del dispositivo.

Paso 2: Configuración de las herramientas de depuración

Intenté utilizar mi depurador BlackMagic conectando cables de puente DuPont entre todos los pines Light Messenger y mi Flipper Zero (asegurado con una protoboard). Luego conecté mi módulo Wi-Fi Flipper Zero (flasheado con el firmware BlackMagic) a los pines 9-12 del Flipper Zero.

¡Sin embargo, descubrí que SWC (Flipper Pin 10) estaba conectado a la interrupción 2 pin de la LIS2DH12, lo que impidió que el depurador de código VS se conecte! Para solucionar esto, modifiqué el archivo app_params.h para utilizar PB2 (Flipper Pin 6) para la interrupción 2 en su lugar. También tuve que mover el cable que viene del pin 10 del Light Messenger para conectarlo al pin 6 del Flipper Zero. Esto permitió que el depurador se conectara, pero el problema seguía ocurriendo.

#define LGHTMSG_INT2PIN &gpio_ext_pb2 // Pin de cabecera 6 = INT2

Consejo para desarrolladores de hardware: Evite usar los pines 10 y 12 de Flipper (SWC, SIO) si quiere permitir conectar el depurador BlackMagic más tarde.

Paso 3: Ajuste de los valores umbral

Después de leer el archivo app_params.h, encontré que los umbrales de interrupción estaban fijados en 60, que determina la fuerza-g necesaria para la detección de movimiento. Bajé los valores a 30, reduciendo la fuerza necesaria para un evento.

Aunque este ajuste afectó ligeramente a la precisión de los barridos a izquierda y derecha, ayudó a descartar problemas mecánicos. Sin embargo, el problema persistía, por lo que sabía que probablemente no estaba causado por un problema de conexión física.

Paso 4: Añadir registros de depuración

Traté de usar CLI (depuración de registro) para capturar eventos, pero por extraño que parezca, el problema parecía desaparecer cada vez que se habilita el registro. Sospeché que esto podría haber cambiado la sincronización lo suficiente como para enmascarar el problema.

Como no podía confiar en el registro, decidí depurar usando señales de sonido.

Paso 5: Uso del sonido para depurar

Modifiqué el código para reproducir

• Un tono de 440 Hz cuando la dirección cambiara en un sentido
• Un tono de 660 Hz cuando cambiara a la otra dirección

Cuando la pantalla dejaba de funcionar, los tonos también dejaban de sonar. Esto significaba que o bien nuestro hilo app_acc_worker se había detenido, o teníamos un problema en nuestra rutina de interrupción, o el LIS2DH12 no estaba disparando interrupciones cuando el dispositivo se movía.

Para investigar más a fondo, quité los cables utilizados para las interrupciones del Flipper Zero(pines 4, 6, y uno de los cables GND). Entonces cogí una resistencia y la conecté entre GND y el pin 4, pero no pasó nada. Moviendo la resistencia a GND y al pin 6, escuché el tono. Volviendo al pin 4, oí el otro tono. Estaba disparando manualmente el código de interrupción; nuestro hilo app_acc_worker seguía procesando eventos, y no se había bloqueado.

Esto era una gran noticia: ¡confirmaba que nuestro código seguía funcionando! Sin embargo, por alguna razón, el LIS2DH12 no activaba las interrupciones cuando movíamos el dispositivo.

Paso 6: Comprobación de los valores de registro

Centrándome en el LIS2DH12, pensé que quizás uno de los registros se estaba reseteando a un valor incorrecto. Pensé que de alguna manera el registro estaba cambiando de valor mientras lo movíamos. Escribí una rutina para registrar los valores de los registros en un archivo de texto en la tarjeta SD del Flipper Zero. Algunos de los registros están marcados como reservados o son para temperatura, así que decidí saltarme esos registros.

Comparando los registros de cuando el dispositivo funcionaba y cuando fallaba, me di cuenta de que el registro 0x22 tenía valores diferentes:

• Estado de trabajo: 0xC0
• Estado de fallo: 0xC8

Aquí hay una copia de la hoja de datos que habla sobre el registro 0x22...

El primer digito (C - o 1100 en binario) significa que I1_CLICK & I1_IA1 estaban habilitados y I1_IA2 y I1_ZYXDA estaban deshabilitados. El segundo dígito (8 - 1000 en binario) indica que se activó el bit "0(1)", que, según la hoja de datos, debe estar a '0' para un funcionamiento correcto.

Paso 7: Corregir el código

Comprobé drivers\lis2xx12_wrapper.c, que habilitaba explícitamente I1_IA1 y deshabilitaba 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);

El fichero drivers\lis2xx12_wrapper.h define lis2dh12_ctrl_reg3_t como:

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;

Para solucionar el problema, establecí explícitamente not_used_01 y not_used_02 a PROPERTY_DISABLE, ¡y el problema desapareció!

Más tarde, me di cuenta de que establecer el valor inicial de nuestra estructura a 0 habría evitado este problema en primer lugar. Actualizando el código a lo siguiente se obtiene el resultado deseado...

lis2dh12_int1_cfg_t int1_cfg = {0};

Una pequeña pero significativa mejora sería renombrar not_used_02 a must_be_cleared para indicar que su valor importa. Esto evitaría errores similares en futuros desarrollos.

Lecciones aprendidas

• Comprueba las variables no inicializadas: Cuando trabajes con bit flags en estructuras, asegúrate de que todos los flags están explícitamente establecidos.
• Evite los pines 10 y 12 de Flipper: Si necesita acceso de depuración, estos pines pueden interferir con las conexiones del depurador BlackMagic.
• Utilice métodos de depuración alternativos: Cuando el registro altere el comportamiento, utilice otro método como el sonido o el motor de vibración.
• Volcar registros: volcar los valores de los registros puede ayudar a validar que el dispositivo está configurado como se esperaba.

¡Este fue un divertido desafío de depuración, y espero que este escrito ayude a otros que trabajan en proyectos de hardware Flipper Zero!

🎬 YouTube: @MrDerekJamison

🎮 Discord: @CodeAllNight

🐱 GitHub: Tutoriales Flipper Zero