STM32 + NetBeans =?

Como sabe, la compatibilidad con las herramientas de GNU y el soporte para GDB hacen que casi cualquier entorno de desarrollo popular sea adecuado para depurar una amplia gama de plataformas integradas, la mayoría de las veces de forma gratuita y legal. En teoría

Lo que sucede en la práctica cuando se trata de hacer amigos con STM32 y NetBeans, y es posible, en principio, obtener un sistema viable con soporte para las últimas piedras, debajo del corte.

Algunas letras

Realmente no quería dejar el microchip. Sin embargo, después de la compra por parte de Atmela, primero cubrieron, tal vez, una de las familias más prometedoras de la cartera de la compañía: PIC32MM, y luego toda la línea MIPS. Se hizo evidente que en el futuro previsible, la transición a ARM es inevitable, porque el microchip durante dos años no ha integrado el soporte de los controladores Atmelovsk en su ecosistema, no le dio ninguna ventaja a "Quédese con nosotros". Por el contrario, la política de precios al alza y las dificultades organizativas tradicionales de la fusión hicieron que los AWP de Atmelovskiye fueran menos atractivos. Al mismo tiempo, apareció un proyecto que el PIC32MZ simplemente encontró. Se ha ganado una masa crítica.

Por qué STM: amplia cobertura de mercado, depuración de presupuesto, un entorno de código abierto gratuito y con todas las funciones basado en código abierto SW4STM32, bueno, el aspecto político: ST Microelectronics es respaldado por el gobierno francés como un recurso estratégico, por lo que parece que la salida repentina del mercado o la adquisición no están amenazadas.

Depuración: primeras impresiones

SW4STM32 se instaló de la manera tradicional: presionando repetidamente el botón Siguiente> (* en adelante, todos los experimentos se realizan en Win7 x64). Se eliminó un proyecto de demostración adecuado para probar la función deseada del paquete de firmware STM32Cube, todo funcionó más o menos desde el primer momento. El primer inicio del emulador JTAG dejó una impresión: todo el ciclo de ingresar al modo de depuración, comenzando desde la conexión y terminando con la parada al comienzo de main () con la actualización del contexto, resulta que puede caber en 1-2 segundos. En comparación con los depuradores de microchips (incluso REAL ICE durante media mitad), ¡la diferencia de velocidad es múltiple!
Y, sin embargo, algo desagradablemente sorprendido.

Lo que está mal con Eclipse / SW4STM32

Una miríada de configuraciones y organización ilógica, elementos de menú ocultos, perspectivas, errores de interfaz y artefactos visuales, falta de botones de acceso rápido y funciones de uso común en la barra de herramientas, pequeños pictogramas y marcadores torpes e ilegibles, la ausencia de "Buscar usos" son en parte subjetivos, y puede adaptarse si lo desea . Pero: regularmente olvida guardar los archivos modificados antes del ensamblaje, aunque todas las marcas de verificación cuando sea necesario; con el guardado manual forzado, no ve cambios, y el ensamblaje incremental resulta ser irrelevante; no hay una reconstrucción completa (Clean and Build) como un solo equipo, y después de la limpieza forzada a través de Clean Project, el ensamblaje falla (¿acceso al archivo?) y se completa con éxito solo después del 4to intento; esto ya no se puede explicar razonablemente. Incluso las primeras versiones de MPLAB X Beta basadas en los antiguos NetBeans 6.xx no tuvieron los mismos problemas hace 10 años que el entorno de desarrollo oficialmente compatible para STM32 tiene hoy.

Además, con SW4STM32, 3 copias de IDEs típicos ya están marcadas en el sistema, ya que además de eso todavía hay MPLAB X firmemente clavado en NetBeans 8.0.1 y algo cercado (es decir, es imposible usarlo para otros idiomas / plataformas), y NetBeans 8.2 para Java y C / C ++.

Resulta que configurar NetBeans 8.2 para que funcione con STM32 eliminará los problemas prácticos descritos de Eclipse, reducirá el número de copias IDE y lo reducirá a una plataforma, aunque versiones ligeramente diferentes.

Herramientas NetBeans 8.2 y GNU ARM

NetBeans es mejor usar 32 bits, porque además de duplicar el consumo de memoria, no se pudieron encontrar las diferencias de la versión de 64 bits.

Google rápidamente encontró una guía de configuración . La diferencia fundamental fue solo en el sistema operativo (tienen Linux contra Win7 x64 para mí), por lo que instalar el * nix-environment MSYS, que es parte del paquete MinGW, se convirtió en un juego de premio. La configuración de la cadena de herramientas debería verse así:


Un punto importante: al agregar la cadena de herramientas GNU ARM, seleccione la familia "GNU MinGW", en cuyo caso NetBeans llamará correctamente a MSYS. Si Cygwin ya está instalado en la máquina, será lógico usarlo, en consecuencia, la familia GNU ARM debe seleccionar "GNU Cygwin".

Lograr una compilación exitosa no fue fácil, pero sí muy simple. Dado que SW4STM32 usa el mismo compilador, mirando la línea de comando de la llamada del compilador en SW4STM32 y copiando las claves faltantes en Propiedades del proyecto → Compilador C → Opciones adicionales


obtenemos exactamente el mismo resultado de salida, pero con una diferencia práctica importante: todo se recopila la primera vez, hay Clean and Build y funciona bien:


Pero este resultado también se puede mejorar agregando el procesamiento opcional posterior a la compilación. Abra el Makefile, y en la sección .build-post: .build-impl add:

.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}} 

(importante: la sangría debe ser un solo carácter de tabulación, no espacios)
Línea por línea: 1: copia el archivo objeto (.elf) de la carpeta de salida a la raíz del proyecto, para facilitar el acceso; 2: genera HEX a partir de elf (puede comentarse si HEX no es necesario); 3: muestra la cantidad de memoria ocupada por segmentos.

El resultado final:


Hasta ahora todo bien.

OpenOCD - las primeras dificultades

En los manuales en línea mencionados anteriormente, programar un chip a través de OpenOCD es simple y rutinario. Se instala la última versión (0.10.0), se toma el archivo de configuración (del kit OpenOCD o de la carpeta de proyecto SW4STM32), se escribe un comando del formulario en Propiedades del proyecto → Ejecutar:


y todo funciona de inmediato. De hecho, este es el caso para familias más jóvenes como STM32F103 y F407, pero estoy interesado en F7 y H7. Con el primero, la versión oficial de OpenOCD 0.10.0 se bloquea con los errores "auto_probe failure" y "motivo de depuración indefinido 7"; estos últimos no son compatibles en absoluto. Probamos todas las asambleas oficiales disponibles 0.10.0 de enero de 2017 y enero de 2018: el resultado es idéntico. Una búsqueda por palabra clave confirma la existencia del problema, aunque no puede nombrarlo masivo; No hay análisis ni solución.

Pero hay una versión que está garantizada para funcionar: desde el kit SW4STM32. Naturalmente, resulta ser mejorado y complementado, con nuevos scripts y soporte para la familia H7. Además, la estructura del archivo se ha modificado en él, y en el complemento los recursos se almacenan en un módulo separado, por lo tanto, para que la utilidad consolidada en una sola carpeta vea sus scripts, se requirió el modificador -s.

Board.cfg para NUCLEO-F767ZI, neto de comentarios, y condensado:

 set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1 

Finalmente, inicie a través de Run Main Project:


El firmware es exitoso, el código se está ejecutando.

Depuración

Se supone que el esquema es el más tradicional: un servidor GDB local en OpenOCD, NetBeans se conecta a él a través de localhost: 3333 a través de TCP. En consecuencia, NetBeans requerirá el complemento Gdbserver.

Es posible simplificar el lanzamiento de OpenOCD a través de un script de murciélago, y dado que una vez completada la sesión va a la consola, tiene sentido repetir el reinicio sin fin:

 :start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start 

Lanzamiento


La versión de SW4STM32 no está escrita explícitamente, pero el servidor está esperando una conexión TCP al puerto 3333. En NetBeans, seleccione Debug → Attach Debugger ... e instale:


La sesión está activa. Terminal OpenOCD:


En apariencia, todo se ve bien: la sesión de depuración está activa, el código se ejecuta. Sin embargo, el problema aún existe.

El problema

En modo de ejecución libre, la ejecución no se puede detener.

Si establece un punto de interrupción antes de comenzar la sesión, cuando ingrese la depuración, se detendrá con la actualización del contexto, la ejecución paso a paso y la visualización / cambio de variables funcionarán, es decir, en principio, todas las funciones básicas necesarias para la depuración completa:


Pero solo hasta el próximo inicio gratuito, después del cual solo queda cerrar y reiniciar la sesión.

Otro problema desagradable está asociado con los puntos de interrupción del software: la función SYSTEM_Halt () se define como __asm__ ("bkpt"), y su funcionamiento lleva a la visualización de un diálogo innecesario:


Cuando hace clic en Descartar y pausar, funciona según sea necesario (es decir, detiene la ejecución), sin embargo, es imposible establecer esta opción de forma predeterminada y deshabilitar la visualización de la ventana por medios estándar.

Antes del montón, me gustaría automatizar el lanzamiento de OpenOCD y conectar el depurador directamente a través de NetBeans.

Sin embargo, objetivamente, la única función que no es suficiente para una depuración más o menos completa es detener la ejecución (también es necesario establecer un punto de interrupción sobre la marcha).

Depuración Depuración

Una búsqueda en Google reveló que problemas similares con NetBeans deteniendo GDB se detuvieron, pero se solucionaron hace varios años. A falta de una idea mejor, las fuentes de NetBeans se descargaron con la esperanza de recorrer el depurador en vivo. Sorprendentemente, pudimos localizar rápidamente el problema antes de llamar a la utilidad externa GdbKillProc.exe, que es esencialmente un contenedor para DebugBreakProcess (pid) de WinAPI. El principio de la utilidad se reduce a una interrupción no intrusiva del proceso (análogo de "kill -SIGINT [pid]" bajo * nix, o Ctrl + C en la consola).

Pero ella no trabaja.

Lo que se prueba

En modo consola, el cliente GDB (arm-none-eabi-gdb.exe) reacciona correctamente a Ctrl + C, es decir, detiene la ejecución del código sin cerrar la sesión y espera más instrucciones.

ps -W y Windows Process Explorer muestran el proceso correctamente, y el PID coincide con la variable interna en NetBeans.

La llamada manual "kill -SIGINT [pid]" del paquete MSYS arroja un error "No hay tal proceso".

Al revisar "taskkill / pid [pid]" se obtiene "El proceso ... no se pudo terminar ... Este proceso solo se puede terminar con fuerza ...", lo que parece indicar un bloqueo del sistema. Con el modificador / f, el proceso se cierra por completo, lo que tampoco es bueno.

En el proceso, resultó que en Windows, la situación con la generación de señales de interrupción no importa, o mejor dicho, de ninguna manera: solo el análogo SIGTERM es compatible de forma predeterminada, lo que corresponde a una reducción general del proceso, y no existe una solución generalmente aceptada.

En Internet, se encontró una utilidad windows-kill, diseñada para emular Ctrl + C y Ctrl + Brk. El proceso encuentra los envíos de interrupción sin errores, pero el cliente GDB aún no responde.

Los experimentos se llevaron a cabo utilizando todas las versiones de 32 bits (NetBeans, ARM Tools, MSYS 1.0), excepto Windows-kill, que se negó a iniciar 32 bits ("... no se pudo iniciar correctamente ..."). Quizás el problema sea precisamente esto, porque, según datos fragmentarios de foros y rastreadores de errores, la profundidad de bits de la utilidad y el proceso deberían coincidir. La dificultad aquí es que ARM no ofrece la versión x64 de la cadena de herramientas para Windows, incluida la única forma de eliminar la heterogeneidad es hacer que la versión x32 de windows-kill funcione, lo que tampoco está claro si es posible bajo Win x64 en principio.

En el medio del proceso, el sistema operativo se reinstaló desde cero y no se notaron cambios en el comportamiento de los sujetos experimentales, incluidas con gran confianza las características de un sistema en particular que se pueden eliminar.

Se requiere asistencia de pasillo

En realidad, todo lo anterior puede considerarse una introducción a este párrafo.
El último paso que queda es hacer que la depuración de STM32 en NetBeans sea real:

requiere un mecanismo de software que funcione para enviar la señal de interrupción SIGINT (Ctrl + C) al proceso del cliente GDB de Windows

La siguiente es una recomendación para establecer la configuración mínima suficiente para verificar / depurar el problema anterior. Si / cuando se puede resolver, el artículo se rehacerá en una simple guía paso a paso sobre cómo configurar NetBeans + OpenOCD para varias familias y placas de depuración diferentes. Se puede completar más funcionalidad a voluntad, ya que tiene una solución básica viable.

Configuración de prueba

Se propone utilizar la placa Blue Pill basada en el STM32F103C8T6 y el clon ST-Link V2 como plataforma de hardware.


Es necesario:

1. Instale la cadena de herramientas integradas de GNU Arm

2. Instale OpenOCD 0.10.0 ( compilación en Win )

3. Registre las carpetas bin de ambos paquetes en PATH (Panel de control → Sistema → Configuración avanzada del sistema → Variables de entorno ... → Ruta).

4. En un lugar conveniente para crear el archivo board.cfg, copie el contenido:

 source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1 

5. Elija el firmware de prueba apropiado (test.elf), el criterio principal es que la ejecución y la detención son claramente distinguibles. Copiar a un lugar conveniente.

6. Desde un lugar conveniente para mostrar el tablero:

openocd -f board.cfg -c "program test.elf verify reset exit"

El firmware debería comenzar. Salida de muestra de OpenOCD a la consola:


7. Desde un lugar conveniente para iniciar el servidor OpenOCD GDB:

openocd -f board.cfg

El código aún se está ejecutando; salida de muestra (la consola permanece bloqueada por OpenOCD):


8. En otra consola o ejecute directamente arm-none-eabi-gdb.exe desde el paquete GNU ARM Embedded Toolchain y ejecute los comandos:

target extended-remote localhost:3333 (el código aún se está ejecutando)
continue (el código se está ejecutando, la consola está bloqueada)
Ctrl+C (código detenido, consola activa)
continue (ejecutándose nuevamente, la consola está bloqueada)


La tarea es eliminar el cliente GDB del estado de ejecución (es decir, emular esencialmente Ctrl + C) mediante programación.

Para averiguar la ID del proceso, use "ps -W" del entorno * nix o Windows Process Explorer (instalado opcionalmente).

Quizás alguien se depure correctamente inmediatamente después de la configuración inicial de NetBeans; dicha información también será útil, especialmente con una descripción detallada del sistema y las posibles características.

Comparta ideas en los comentarios, y espero que al trabajar juntos podamos convertir un experimento audaz en una guía útil para configurar una herramienta aún más útil.