STM32 - Depuración de problemas usando openocd y st-link

6

Intento seguir esta guía "Instalación de una cadena de herramientas para Cortex-M3 / STM32 en GNU / Linux" (disponible: enlace ) con la placa de desarrollo STM32-H103 de Olimex. Todo funciona como se esperaba hasta el momento en que necesito copiar mi programa compilado en flash usando openocd.

Siguiendo las instrucciones, inicio el servidor openocd ('openocd -f openocd.cfg') y luego telnet ('telnet localhost 4444'). Inicialmente, al iniciar el servidor openocd no se inicia la salida:

Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : Target voltage: 2.038896
Error: init mode failed
in procedure 'transport'
in procedure 'init'

intentarlo de nuevo, sin embargo, parece funcionar ... Sin embargo, 0 puntos de interrupción y puntos de control parecen sospechosos.

Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : Target voltage: 2.054665
Info : stm32f1x.cpu: hardware has 0 breakpoints, 0 watchpoints

En este estado no puedo detener ni probar el dispositivo.

> reset halt


in procedure 'reset'
> flash probe 0
Cannot identify target as a stm32x
auto_probe failed
in procedure 'flash'

Luego encontré este artículo en el sitio web de NuttX ( enlace ) que parece Ayúdame un poco (no estoy usando el NuttX RTOS, sin embargo, solo el metal desnudo). Siguiendo el artículo y manteniendo presionado el botón de reinicio hasta que se agote el tiempo de espera de 'reiniciar', puedo probar el dispositivo con éxito. También tenga en cuenta que ahora hay 6 puntos de interrupción y 4 puntos de observación.

Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : Target voltage: 2.047244
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

> reset halt
timed out while waiting for target halted
TARGET: stm32f1x.cpu - Not halted

in procedure 'reset'
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000250 msp: 0x20005000
> flash probe 0
device id = 0x20036410
flash size = 128kbytes
device id = 0x20036410
flash size = 128kbytes
flash 'stm32f1x' found at 0x08000000

Sin embargo, cuando programo y ejecuto el dispositivo, obtengo el siguiente mensaje de error ...

> stm32f1x mass_erase 0
stm32x mass erase complete
> flash write_bank 0 main.bin 0
wrote 9704 bytes from file main.bin to flash bank 0 at offset 0x00000000 in 0.719990s (13.162 KiB/s)
> reset run


in procedure 'reset'
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 100ms
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 300ms
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 700ms
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 1500ms
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, GDB will be halted. Polling again in 3100ms

En esta etapa no puedo ver el LED parpadeando en el tablero como sugiere la guía. ¿Alguien tiene alguna idea de lo que está mal?

[EDITAR] He encontrado que el archivo main.elf (en lugar de main.bin) parpadea no hace que se generen los errores anteriores después de 'reinicio', sin embargo, todavía no veo el LED parpadeando.

Luego use gdb con el comando 'arm-none-eabi-gdb -tui --eval-command="target localhost remoto: 3333" main.elf'.

Si ingreso 'c' para continuar, obtengo

(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
0x00010100 in ?? ()

Y si ingreso 's' para el paso, obtengo

(gdb) s
Cannot find bounds of current function
    
pregunta matben243

2 respuestas

6

Así que descubrí mi problema ...

De forma ingenua, creía que el conector JTAG (a través del st-link v2) era suficiente para alimentar la placa. Supongo que intentar ejecutar el código (y parpadear el LED) mientras que solo alimentar la placa a través de los pines JTAG no pudo suministrar suficiente corriente y la placa siguió reiniciando (por lo tanto, la conexión JTAG se rompería).

En pocas palabras, asegúrese de que el cable USB esté conectado a la placa (y a una fuente de alimentación) para alimentar la placa.

    
respondido por el matben243
0

Creo que ya casi llegas, con algunas advertencias en mi sistema de prueba:

  • Software: Win7, OpenOCD 0.8.0, GDB
  • Hardware: STM32F4 Discovery (con ST-LINK V2 integrado)
  • Firmware: CoOS RTOS, tarea flash LED muy simple

Encontré que si flasheo el archivo .bin y luego emito un "reinicio", obtengo actividad de LED.

Creo que puedes tener un problema con tu compilación.

    
respondido por el markt

Lea otras preguntas en las etiquetas

Comentarios Recientes

gcc -I. -Wall -Pthread -I / usr / include -I / include / stm32crypt.h -I / include / wmem -fopenocdNotice que OPENOCD ya estaba instalado en mi sistema. OpenOCD usa System V Binary, y algunos de los sistemas en los que se ejecuta se han actualizado y actualizado muchas veces, esto significa que necesitamos reconstruir nuestra versión actualmente instalada antes de usarlo con OpenOCD. Otro enfoque es actualizar nuestro sistema a la versión dada de OpenOCD de 4.3 o superior; sin embargo, estamos tratando de publicar... Lees verder