我正在使用命令行进行stm32开发。CubeIDE和Atom对于我的机器规格来说太重量级了。
我编译了一个带有调试支持的 elf 和 bin 文件，并将 bin 上传到 stm32。这是一个简单的LED闪烁程序，它可以工作。
我启动stlink-server，它报告端口 7184。在另一个终端中，我键入：
$ arm-none-eabi-gdb
file app.elf
target remote localhost:7184
我在大约 30 秒内没有得到响应，然后arm-non-eabi-gdb报告：
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
stlink-server报告：
Error: recv returned 0. Remote side has closed gracefully. Good.
但不好！
那么，我该怎么办？我似乎无法停止 stm32、设置断点、运行等。
我正在运行来自各种来源的stlink-server，arm-none-eabi-gcc和arm-none-eabi-gdb的大杂烩，这可能没有帮助。
我使用的是中文 ST-LINK v2，我听说它可能没有连接所有引脚进行调试，并且我必须短路一些引脚。不过，它可以正常上传垃圾箱。
Update 1好的，也许有一点进展(？？
我开始st-util，它报告：
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...
因此，在单独的控制台中，我键入：
$ 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'
哦。也：
(gdb) r
Don't know how to run. Try "help target".
所以我觉得我越来越近了，看来我可以设置断点了。也许我以错误的顺序运行了命令。
我想也许我必须做：
exec app.elf
但这似乎不尊重断点。
嗯。
更新 2传奇仍在继续。
这似乎更好：
$ $arm-none-eabi-gdb
(gdb) target remote localhost:4242
(gdb) file app.elf
(gdb) b 26
continue
这似乎尊重断点;但调试器报告：
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
嗯。似乎该程序现在不再处于main()，而是处于信号陷阱中，因此i不在当前上下文中(即使我将其定义为main(。
所以到达断点基本上会导致机器重置？？这有点违背调试的重点。所以我想我一定做错了什么(？(，有更好的方法吗？
<小时 />更新3
我切换到Arduino IDE并上传了一个草图。使用上述过程，我没有遇到信号陷阱问题。我能够调试我的程序，设置断点并检查变量。好。Arduino显然包含了一些我没有添加到我自己的非Arduino代码中的"秘密调味料"。
所以，它大多有效。主要。
尝试在加载前重置 MCU：
target remote localhost:4242
file app.elf
monitor reset halt
load app.elf