Estoy escribiendo algunos programas de prueba para conocer el STM32F4 (ARM Cortex M4). La placa de desarrollo que estoy usando tiene U-Boot preinstalado en flash. Cuando la placa está en funcionamiento y U-Boot muestra su indicador de comando,
- Me estoy conectando con OpenOCD + GDB a través de JTAG
- cargar mi imagen binaria en la RAM (OpenOCD:
load_image) - restablecer la CPU (OpenOCD:
reset init) - y configura la PC en la ubicación que deseo ejecutar (GDB:
set $pc=0x2000001d) - y ejecute (GDB:
continue)
El problema
La mayoría de las veces esto funciona bien. Sin embargo, varias veces tuve el problema de que cuando la CPU está en estado de FUNCIONAMIENTO, de repente, OpenOCD muestra este mensaje:
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms
Si mi observación es correcta, esto solo sucede cuando
- Estoy reiniciando la placa de desarrollo con el botón de reinicio
- y escribiendo algo en el indicador de U-Boot que aparece en ese momento.
Cuando en lugar de U-Boot algún otro programa está presente en flash, este problema no parece ocurrir.
Mi suposición
Actualmente, estoy asumiendo que esto se debe a que U-Boot escribe en la ubicación de RAM desde la que se emitió el comando continue . No sé cómo continue funciona exactamente, pero mi teoría es que este comando afecta a la circuitería de depuración de alguna manera y, por lo tanto, escribir en esa dirección RAM está causando problemas.
Cuando mi otro programa está presente en flash, todo funciona bien. Incluso pulsar el botón de reinicio funciona. Creo que es porque su espacio de memoria es muy pequeño, por lo que 0x2000001d no se ve afectado.
Mis preguntas
- ¿Qué está haciendo exactamente
continue? ¿Es algo más que simplemente configurar la CPU en modo de ejecución? ¿Afecta a los puntos de ruptura de alguna manera? - ¿Mi suposición que expliqué arriba es plausible?