Introducción
Después de haber aprendido cómo compilar nuestro proyecto de forma cruzada para nuestra arquitectura destino y después de haber cargado el firmware resultante en nuestra tarjeta de desarrollo favorita, aún nos queda por aprender algo básico: cómo poder depurar nuestro firmware para solucionar posibles fallos que nos encontremos.
Este post pretende explicar cómo debes configurar Netbeans para poder realizar una depuración cruzada contra el hardware sobre el que correrá tu firmware utilizando para ello el IDE Netbeans.
Qué necesitamos
Para poder seguir este post necesitarás haber leído los anteriores posts que explican cómo configurar una toolchain cruzada en Netbeans y cómo cargar el firmware en tu tarjeta de desarrollo con Netbeans y OpenOCD. Deberás tener instaladas y configuradas todas las herramientas explicadas en dichos posts.
Además, asumo que sabes cómo depurar utilizando Netbeans y que tienes experiencia depurando sistemas empotrados y firmware para microcontroladores.
Configurando Netbeans
Una vez que hemos seguido paso por paso los posts mencionados anteriormente, tendremos nuestro Netbeans configurado para compilar de forma cruzada sobre nuestra arquitectura destino y habremos configurado también el IDE para poder realizar la descarga del firmware generado en nuestra tarjeta de desarrollo. También tendremos cargado un proyecto que podremos utilizar a modo de plantilla para futuros proyectos, stm32f4discovery_tmpl, y en el que dispondremos de los scripts necesarios para lanzar OpenOCD, herramienta que utilizaremos como gdbserver durante nuestra sesión de depuración.
El último paso que nos queda ahora es configurar Netbeans para que pueda conectarse en remoto a la instancia de OpenOCD que quedó en ejecución cuando cargamos el firmware sobre la tarjeta de desarrollo. El proceso consistirá en iniciar una instancia de GDB para nuestra arquitectura (en nuestro caso arm-none-eabi-gdb), que si recordamos, fue configurada en el primer post de la serie.
Esta instancia de GDB, una vez que ha arrancado, se conectará remotamente a la instancia de OpenOCD que está en ejecución y que será quien le envíe información de estado del sistema, lecturas de los registros, breakpoints y demás fauna. Además, recibirá los comando procedentes de GDB, como por ejemplo parada del procesador, reinicio y configuración de breakpoints, y los enviará a la tarjeta de desarrollo sobre la que estamos depurando.
Finalmente, nuestra instancia de GDB utilizará a NetBeans como frontend, mostrando su salida y recibiendo comandos a través de este IDE.
Para poder realizar todo ésto con facilidad, necesitaremos descargar e instalar el plugin de gdbserver para Netbeans en nuestro IDE. Lo descargaremos e instalaremos de la manera habitual (ya sabéis, Tools --> Plugins, pestaña Downloaded y Add Plugins...).
Una vez instalado el plugin, será necesario configurar nuestro proyecto para poder depurar correctamente, para ello abrimos el panel de Propiedades del Proyecto y pulsamos en la opción Debug. Aplicaremos las modificaciones para todas las configuraciones, así que en Configurations seleccionamos la opción All Configurations.
Las opciones a configurar serán las siguientes:
- Debug command: Esta línea indica qué comando se invocará para llevar a cabo la depuración. Nosotros usaremos el depurador cruzado para nuestra arquitectura, que como ya sabemos es arm-none-eabi-gdb.
- Gdb init File: Aquí deberemos indicar el archivo de inicialización que será pasado a GDB cuando éste arranque. En nuestro caso, este archivo contiene sólo dos comandos, load, que carga la imagen a depurar en el depurador y c, que inicia la ejecución del firmware en modo depuración. De este modo, GDB realizará esas dos operaciones de manera automática.
Ahora si, empezamos a depurar
Bueno, pues ya llega lo "divertido", donde podremos ensuciarnos de verdad las manos. Ya podemos ponernos a depurar. Para empezar, lo mas aconsejable es poner algún breakpoint en nuestro código para que éste se detenga en un punto cercano al que sospechamos que puede fallar. En nuestro caso, lo haremos en el punto de entrada de nuestro firmware, la función main(), por ejemplo en la línea donde se invoca a la función HAL_Init().
Con nuestro inocente breakpoint configurado, cargamos nuestro firmware en la tarjeta de desarrollo. Por si no nos acordamos del post anterior, con pulsar sobre F6 es suficiente.
Una vez que nuestro firmware está corriendo, OpenOCD seguirá funcionando, esperando alguna instancia de GDB. Si abrimos el script flash-openocd.cfg del que hablamos en el anterior post, veremos la línea gdb_port 3333. Esta línea configura OpenOCD para que escuche en el puerto 3333, que es donde tendremos que decirle a GDB que conecte.
Con todo ésto en cuenta, abrimos el menú desplegable situado al lado del botón de depurar y pulsamos sobre la opción Attach debugger...
En esta ventana configuraremos como debugger gdbserver (ya que tenemos uno funcionando en este momento), y como Target configuraremos remote:3333, para indicar a GDB que vamos a utilizar un gdbserver remoto en el puerto 3333. Una vez que pulsamos sobre OK, GDB arrancará, se conectará con OpenOCD y éste, según configuramos en el script flash-openocd.cfg, reiniciará nuestro procesador. GDB configurará entonces el breakpoint que instalamos y la ejecución se detendrá en ese punto:
A partir de ahora, ya podremos depurar nuestro código de la manera habitual en la que depuramos cualquier software con Netbeans, pero con la restricción de que tanto los breakpoints como los watchpoints que podremos configurar estarán limitados en número dependiendo del hardware que utilicemos.
Para finalizar la depuración, pulsamos sobre el botón de fin de la depuración, lo que detendrá GDB, haciendo que éste se desconecte de OpenOCD, que a su vez reiniciará el micro dejándolo en modo de ejecución normal antes de detenerse.
