我想设置以下环境：我有一个STM32H753I-EVAL2评估板，已连接到Windows PC。到目前为止，我仍在使用STM32CubeIDE在此PC上进行本地开发和调试。由于多种原因，我的代码源在Linux服务器上（Samba安装），因此需要花费很多时间来构建项目。因此，我想在Windows计算机上的Linux服务器上进行开发。
编译工作正常（并且速度更快），但问题在于调试。我知道可以进行远程调试，Eclipse（我正在使用OpenOcd）中的Debug Configuration窗口允许连接到远程GDB服务器。我不知道如何在将连接到STM32板的Windows机器上启动GDB服务器？
答案 0 :(得分：1)
很抱歉获得“对自己的回答”，但我认为这可能对其他人（甚至在我几周后忘记了的时候对我来说都是有用的）。）
这是怎么做。
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
即使我偶尔在调试过程中遇到一些不稳定因素，此设置也可以正常工作。
答案 1 :(得分：1)
我看到两个（可能三个）选项
我已经使用第二个选项成功调试了我的目标，使用任意 GDB，例如 gdb-multiarch 命令行和（非 STMCube 化的）Eclipse CDT
替代 GDB 服务器
你可以试试STLink open source。我做到了。问题是，您的设备可能没有得到正确支持。我从 Github 构建了 1.6.1 以启用对 STM32G03x 设备的支持。移动到此版本使其能够检测设备，并且我可以使用 st-flash 对设备进行编程，但调试器无法使用（尝试更改寄存器，它更改了错误的寄存器，尝试单步执行程序，它立即崩溃）。
尽管尝试一下.. 安装（或构建）既简单又快捷，因此值得检查您的设备是否可以正常使用。
Openocd 是另一种选择，但似乎不支持 SWD 连接。我尝试了一个据称有补丁的版本，但没有运气。
如果您可以使用这些开源替代方案之一，它们还有另一个优势，您可以在 Raspberry PI 之类的设备上运行它们，这意味着您不必让 PC 靠近目标.
从STMCubeIDE单独运行GDB服务器
对于 Windows，请参阅 OP 的答案。对于 Linux，我会这样做更改路径名以适合您的安装
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
我是怎么做到的？首先从STMCubeIDE启动调试会话，然后运行
ps aux | grep gdbserver
然后我们可以看到 Eclipse (STMCube) 如何启动 gdbserver 并从那里开始工作。
如果您发现它抱怨 .so 文件，请从 STMCube 安装中找到该文件，并确保包含它的目录的路径在 LD_LIBRARY_PATH 中（按照我的示例）
您还可以使用 --help 启动程序以显示更多选项。
如果添加 -e（持久），您可以断开连接并重新连接 GDB 客户端，而无需重置目标（尽管它会在初始调用 gdb 服务器时重置，即使没有 -k）。
GDB 串行
这是目标实现协议的 GDB 服务器端的地方。 GDB 存根通常在异常处理程序中运行。这通常是您的断点处理程序，但您也可以将其设置为未处理异常的默认处理程序，或者例如 ctrl-c 中断。
我最近在谷歌上搜索了很多关于这个问题，基本上当人们在论坛上询问时，他们通常会得到“这里是龙”或“你为什么不使用 JTAG？”的回答。
因此，您可能想知道，这方面的驱动程序位于 git://sourceware.org/git/binutils-gdb.git 下的 GDB 源 gdb/stubs 中。文档是 here。 那里没有用于 arm 的存根实现。 真的很可悲，我曾经经常在我工作的地方使用 GDB 远程串行，其中一些目标确实是 ARM .操作系统是生态系统。
那么，ecos GDB 存根可以移植到裸机吗？给它一个很好的外观，我相信是的，他们可以。存根基于来自 GDB 源的存根，但它们受到 Ecos 和 Redboot 构建宏和版权的严重污染（原始文件由 HP 编写并无版权发布）。我们不知道 Ecos 存根可能包含哪些错误（我当天至少修复了一个，我不记得我是否提交了补丁）。我们不知道他们是否真的正确支持最新的架构。而且，我们不知道，在那之后，他们是否只是简单地使用了太多内存——我的 STM32 有 8K 的 SRAM，我已经看到默认大小为 2K 的缓冲区（不是说这是必要的，但您会看到工作需要如何在这里完成..)
所以这第三个选项，我有一天会重温这个选项，但就目前而言，对我来说，这是不可能的。