I have:
- A proprietary prototype ARM board (Cortex-M3 based) with eCos OS
- The board has the programmed RedBoot bootloader
- Serial line (RS-232)
- GDB debugger for ARM (arm-eabi-gdb)
- Host OS is Windows/Cygwin and/or Linux (actually, doesn’t matter)
Problem: GDB debugger cannot connect to the target over the serial line.
What I want: is to sniff the packets of the GDB remote protocol in order to undestand whether the GDB stub on the target is alive and operating.
Details: RedBoot has an option to pass the target’s control to the built-in GDB stub. I know that the RedBoot is alive, I can connect to it and send it commands over the serial line. The RedBoot manual says that the switch to the GDB stub can be made by typing $ or + symbols (which are actually the prefixes of the GDB remote protocol packets). It seems to work for when I send those symbols the terminal dies. But I’m not sure if the RedBoot was compiled with the GDB stub support (don’t ask me why :-)).
Then, when I try to connect to the board with my GDB debugger I get the following picture (on 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...
The port is correct, the baudrate as well. Actually the same output I get if I try to do the same with another serial port which is not connected with anything.
What I want to know is does GDB stub send back anything or not?
Intuitively I thought that probably
set verbose on
would help, but GDB manual says it has very a limited effect and my case is beyond it.
May be it is possible to compile GDB debugger with a macro which enables debug logging?
Do this (before
target remote):