STM32F3 Discovery + complemento GNU ARM + OpenOCD: no se puede cargar el binario en la placa

Estoy usando el complemento GNU ARM para Eclipse con Open OCD como depurador. Esto es en Windows 10 x64. El problema al que me enfrento es el siguiente error al intentar depurar o ejecutar el programa de muestra:

Error en la secuencia de inicio final
No se pudo ejecutar el comando MI: cargar C:\Development\stm32-test\Debug\stm32-test.elf
Mensaje de error del back-end del depurador: Error al
cargar
No se pudo ejecutar el comando MI: cargar C:\Development\stm32 -test\Debug\stm32-test.elf
Mensaje de error del back-end del depurador: Falló la carga
Falló la carga

Hay varios tipos de plantillas de proyecto STM32 que ofrece el complemento ARM. En particular, está el "proyecto STM32Fxxx C/C++", y funciona sin problemas. Pero está incluido con la versión anterior de la biblioteca STM32. Quería usar el STM32F3Cube más reciente, así que usé la otra plantilla: "Hello World ARM Cortex-M C/C++ project", según la recomendación de este artículo . Está diseñado para usarse con el STM32F3Cube, y es el que no puedo cargar en la placa.

Dígame qué información adicional se necesita para tratar este problema, o cómo puedo recopilar registros más detallados, etc.

PD He comparado los ajustes de configuración de depuración entre los proyectos que funcionan y los que no funcionan, y no encontré ninguna diferencia. El mismo archivo .cfg, junto con todo lo demás. ¿Mi .elf está siendo rechazado porque tiene algún problema?

Tal vez sea una pregunta tonta, pero ¿está seguro de que se está generando su archivo .elf? ¿Es correcto el camino?
@bitsmack: sí, triplemente comprobado. Incluso movió el .elf a una ruta diferente, convirtió las barras de Windows en barras de Unix, etc. Siempre el mismo error.
@bitsmack: Acabo de intentar lo siguiente: abrí el proyecto problemático -> Configuraciones de depuración, y en lugar del binario de este proyecto, especifiqué el elfo del otro proyecto de trabajo que mencioné. Entonces, usé la configuración de este proyecto para lanzar un .elf diferente, y funcionó. Aparentemente, hay algo en cómo se compila el propio .elf. ¿Alguna idea?
¿Las opciones de tamaño de RAM y tamaño de Flash en su proyecto coinciden con la placa de destino? Y también, hay una parte en el artículo, donde tienes que modificar la dirección de inicio de Flash en el script mem.ld. ¿Todos estos pasos se realizan en su caso?
@BenceKaulics: eso fue todo, ¡me perdí la parte del artículo sobre el ajuste de la dirección flash! Gracias, por favor publique esto como una respuesta.

Respuestas (1)

Por el mensaje de error, parece que el depurador no puede ubicar dónde comienza Flash, por lo que no puede cargar el archivo.

En la plantilla F4 HAL Eclipse, esta dirección de origen de Flash está configurada correctamente para un STM32, pero porque está utilizando un proyecto Cortex-M general, por lo que esta dirección no es correcta para un STM.

Este paso se describe en el artículo que ha mencionado. Del artículo :

Necesitamos configurar cómo se mapea la aplicación en la memoria de la MCU. Este trabajo lo realiza el editor de enlaces (ld), que utiliza los tres archivos .ld dentro de la carpeta /ldscripts de Eclipse. El archivo que nos interesa es mem.ld, y necesitamos cambiar la dirección de origen de FLASH de 0x00000000 a 0x08000000, como se muestra a continuación:

...
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
...

Este valor se puede obtener de la hoja de datos. Aquí está la parte relevante:

ingrese la descripción de la imagen aquí

STM32F3 Discovery + complemento GNU ARM + OpenOCD: no se puede cargar el binario en la placa
RespuestasAquíPolítica de privacidad1y, 0v