Yo tengo:

Una placa ARM prototipo patentada (basada en Cortex-M3) con eCos OSEl tablero tiene el gestor de arranque RedBoot programado.Línea serie (RS-232)Depurador GDB para ARM (arm-eabi-gdb)El sistema operativo host es Windows / Cygwin y / o Linux (en realidad, no importa)

Problema: El depurador GDB no puede conectarse al destino a través de la línea serie.

Lo que quiero: es rastrear los paquetes del protocolo remoto GDB para comprender si el código auxiliar de GDB en el destino está activo y en funcionamiento.

Detalles: RedBoot tiene una opción para pasar el control del objetivo al stub de GDB incorporado. Sé que RedBoot está vivo, puedo conectarme y enviar comandos a través de la línea serial.El manual de RedBoot dice que el cambio al código auxiliar de GDB se puede realizar escribiendo los símbolos $ o + (que en realidad son los prefijos de los paquetes de protocolo remoto de GDB). Parece que funciona para cuando envío esos símbolos, el terminal muere. Pero no estoy seguro de si el RedBoot fue compilado con el soporte de código auxiliar de GDB (no me pregunte por qué :-)).

Luego, cuando intento conectarme a la placa con mi depurador GDB, obtengo la siguiente imagen (en Windows):

(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...

El puerto es correcto, la velocidad de transmisión también. En realidad, la misma salida que obtengo si trato de hacer lo mismo con otro puerto serie que no está conectado con nada.

Lo que quiero saber es si el talón de GDB envía algo o no?

Intuitivamente pensé que probablemente

set verbose on

ayudaría, pero el manual de GDB dice que tiene un efecto muy limitado y mi caso está más allá de eso.

¿Es posible compilar el depurador GDB con una macro que habilita el registro de depuración?