Está bien. Respuesta larga:los puntos de interrupción del hardware generalmente se establecen escribiendo en algunos registros especiales de la CPU. Esto lo hace gdb. Si gdb muere, puede dejar los instalados en la CPU. Supongo que su implementación (de gdb) no los borra ni los examina cuando se conecta a su objetivo. Para ubicarlos, necesitaría enumerar el contenido de los registros de puntos de interrupción de hardware. en su CPU (no sé cómo hacer esto en STM32). La solución alternativa sería (suposición informada) sería esta:establezca algunos puntos de interrupción de HW (por lo general, solo hay unos pocos, rara vez más de 8) usando gdb, luego elimínelos todos. Esto debería sobrescribir y luego limpiar esos registros hw. Una vez que establezca esos puntos de interrupción (antes de eliminarlos), "continúe" (por si acaso, ya que gdb establece puntos de interrupción solo en ese momento).
Lo siguiente me ayudó:
# Ones I hit the SIGTRAP:
(gdb) f 0 # Show the current stack frame of the current thread.
#0 0x4003ed70 in [email protected]@GLIBC_2.4 () from /opt/CodeSourcery/arm-2011.09/arm-none-linux-gnueabi/libc/lib/libpthread.so.0
# The fragment of interest is the current address: 0x4003ed70.
# Set the hardware assisted breakpoint at the current address:
(gdb) hbreak *0x4003ed70
# Continue execution (without hitting SIGTRAP):
(gdb) c
# Continuing.
SIGTRAP debe ser una instrucción de punto de interrupción que se está ejecutando.
Depure esto inspeccionando su puntero de instrucción, lo más probable es que apunte a una dirección que contenga la instrucción BKPT (tendrá que buscar cuál es el código real).
A partir de ahí, tendrá que trabajar hacia atrás en función de la pila y el puntero de instrucciones y ver si está donde espera estar. Puede haber una serie de cosas que causen esto, desde GDB insertando una instrucción de punto de interrupción que no pudo borrar, hasta daños en la memoria.