I'm using the command-line to do my stm32 development. CubeIDE and Atom are too heavyweight for the specs of my machine.
I compile an elf and bin file with debug support and upload the bin to the stm32. It is a simple LED blink program, and it works.
I start stlink-server, and it reports port 7184. In another terminal I type:
$ arm-none-eabi-gdb
file app.elf
target remote localhost:7184
I do not get a response for about 30 seconds, then arm-non-eabi-gdb reports:
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
stlink-server reports:
Error: recv returned 0. Remote side has closed gracefully. Good.
But not good!
So, what do I do? I can't seem to halt the stm32, set breakpoints, run, etc..
I'm running a mish-mash of stlink-server, arm-none-eabi-gcc, and arm-none-eabi-gdb from various sources, which might not be helping.
I'm using a Chinese ST-LINK v2, which I hear might not have all the pins wired up for debugging, and that I have to short some pins. It uploads the bin OK, though.
Update 1 OK, perhaps a little progress (??)
I start st-util, which reports:
2020-07-06T14:50:03 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
2020-07-06T14:50:03 INFO gdb-server.c: Listening at *:4242...
So then in a separate console I type:
$ arm-none-eabi-gdb
(gdb) target remote localhost:4242
(gdb) file app.elf
(gdb) load app.elf
You can't do that when your target is `exec'
Oh. Also:
(gdb) r
Don't know how to run. Try "help target".
So I think I'm getting closer, It appears that I can set breakpoints. And maybe I've run the commands in the wrong order.
I think maybe I have to do:
exec app.elf
but that doesn't seem to respect the breakpoints.
Hmmm.
Update 2 The saga continues.
This seems better:
$ $arm-none-eabi-gdb
(gdb) target remote localhost:4242
(gdb) file app.elf
(gdb) b 26
continue
That seems to respect breakpoints; but the debugger reports:
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0800000c in _reset ()
(gdb) print i
No symbol "i" in current context
Hmmm. It seems that the program is now no longer in main(), but in a signal trap, and hence i is not in current context (even though I defined it it main).
So reaching a breakpoint basically causes the machine to reset?? Which kinda defeats the point of debugging. So I think I must be doing something wrong (?) and there's a better way of doing it?
Update 3
I switched to the Arduino IDE and uploaded a sketch. Using the procedure above, I didn't get the signal trap problem. I was able to debug my program, set breakpoints, and inspect variables. Nice. The Arduino is obviously incorporating some "secret sauce" that I had not added to my own non-Arduino code.
So, it mostly works. Mostly.