高版本CubeIDE下使用DAP-LINK教程

背景

笔者此前在CSDN上写了两篇文章详述了如何在STM32CubeIDE下使用DAPLINK：

在Stm32CubeIDE环境下使用DAP-Link仿真
通过External Tools在STM32CubeIDE下使用DAP-LINK

坏消息是，由于CubeIDE的不断更新，目前以上两种方式都已经被官方屏蔽，均无法正常使用DAPLINK在CubeIDE下调试。使用时CubeIDE界面会报错：“Could not verify ST device”，且Openocd界面报错：invalid command name “WriteDP”。

在很长一段时间内，笔者并不知晓，因为目前多数时间都在使用JLINK，后面据网友反馈，官方已经将Openocd屏蔽。官方此举实在刺激了笔者，就想强推ST-LINK是吧，那么，针对ST官方的这种强势操作，我们还能怎么应对呢，且看下文：

单片机调试原理

为了使读者理解程序调试的整个流程，不再被各种自以为是的IDE在调试上使绊子，设门槛，我们先来看看程序是如何调试的。

目前常见的交互调试软件是GDB，其全名为：GNU Symbolic Debugger，通常它运行在用户PC上，提供了各种调试所需的接口，从而使用户可以直接获取处理器的控制权（下载启动、停止程序（打断点）、监测、修改寄存器和内存）；而GDB软件提供的这些面向用户的统一接口，最终都要被调试器硬件（ST-LINK等）解释为目标处理器的调试模块的具体指令去执行，由此可见，处理器的调试模块要协同处理器本身及其外围各个外设的动作，该模块的设计过程在单片机中比处理器本身还要繁琐。但对于用户来说，调试时，只需要关心调试器是否能正常和目标处理器连接，并向上为用户提供GDB服务即可。GDB命令需要由命令行执行，即使它已经很强大了，但对用户来说，它还不够友好，因此通常IDE调用GDB软件时，提供了图形化界面给用户，使得用户不需要自己输入命令从而执行调试。

通过以上介绍，想必读者对调试工作流程还未全部理解，我们在此展示一个简图：

通过上图我们可以宏观的了解PC端对MCU的调试所经过的链路，因此OpenOcd在调试过程中，其实是充当了类似于调试器驱动的角色，用以将用户的GDB命令最终转换为具体调试接口协议的电信号。GDBServer一般提供调试服务器供用户使用，其通讯一般使用TCP/IP协议，因此，这也就是为什么在OpenOcd和硬件完成连接后，会提供3333端口的原因。该端口就是为用户提供，用于访问MCU硬件的。大多数情况下，我们一般都是在本机调试，因此，连接的都是本地主机，可以通过Localhost或127.0.0.1访问。

有了以上了解，我们就大概可以知道，CubeIDE目前的高版本中，为用户提供调试器应该是动了手脚的，导致我们无法正确的连接到目标MCU。于是，想要在CubeIDE下使用DAP-LINK，只需要三步：

使用OpenOcd连接到目标主机，并开启GDB服务
使用arm-none-eabi-gdb.exe访问本地主机的GDB服务器
arm-none-eabi-gdb.exe由CubeIDE来调用

看起来很简单，实际上，也确实没几步要做，后续我将参考前两篇文章的方法，分别使用独立脚本的方式以及CubeIDE中的External Tools方式演示使用GDB进行调试。

准备工作

1. Openocd

看过笔者前两篇文章的读者应该知道，Openocd的使用需要一个interface配置文件以及一个target配置文件以确定调试器硬件和目标mcu型号。Openocd在CubeIDE的环境下已经自带，并且对应的配置文件也有提供。读者可以根据需要到自己目录下寻找。

虽然，CubeIDE自带了，但是为了防止ST再搞事情，笔者此处不使用CubeIDE自带的Openocd，而选择自己下载，此处给出下载链接：OpenOcd 。

下载后，为方便使用，需要将openocd.exe加入环境变量path中：

复制openocd.exe所在路径，对于本文示例，路径为：C:\Develop_Software\OpenOCD-20210519-0.11.0\bin ；读者的路径应根据自己的安装情况选择。
进入：控制面板->所有控制面板项->系统->高级系统设置->环境变量->系统变量->Path->编辑->新建，添加以上路径。
这一步骤，保证了openocd命令在各个工作路径下都能正常执行，笔者这里说的比较简略，读者可以自行百度如何将命令加入环境变量path。

2. arm-none-eabi-gdb

arm-none-eabi-gdb.exe是GCC For ARM编译器工具链中的其中一个组件，专门用于arm处理器的调试。该文件CubeIDE同样自带了，笔者这里同样使用自己下载的GCC For ARM编译器工具链，同样附上下载链接：arm-none-eabi-gcc。

此处读者也可以使用CubeIDE自带的，毕竟，ST应该不会在编译器工具链上搞事情。

同样，为了方便使用，需要将arm-none-eabi-gdb.exe所在路径加入环境变量path中，过程笔者不再过多赘述。

3. 测试工具链

为了使后续过程顺利，读者应保证自己的openocd.exe及arm-none-eabi-gdb.exe在任意路径下都能执行，笔者在此给出测试截图：

Openocd测试：

arm-none-eabi-gdb测试：

Openocd及arm-none-eabi-gdb两个命令均能正常响应，则证明前面加入环境变量path成功，如读者尝试失败，请检查自己第一步与第二步是否操作到位。

独立脚本使用Openocd

在**“在Stm32CubeIDE环境下使用DAP-Link仿真”**一文中，笔者介绍了如何使用脚本执行openocd。当时笔者并未进行命令路径全局变量path的操作，故该脚本只能在openocd目录执行，此处，因为openocd命令已经加入环境变量，因此可以放在任意目录执行。

笔者在本文中的开发板是STM32F405，故脚本内容为：

openocd.exe -f interface\cmsis-dap.cfg -f target\stm32f4x.cfg

将脚本加以修饰后：

%关闭命令回显%
@ echo off
%打印提示信息%
echo Openocd Runing.........
%执行OpenOCD服务%
openocd.exe -f interface\cmsis-dap.cfg -f target\stm32f4x.cfg
%防止控制台窗口关闭%
pause

将以上内容粘贴保存为txt文件，修改后缀名为.bat，即可运行

运行结果如下，可以看到，Openocd执行后，成功开启了3333的端口，等待用户访问：

当然，对于其他的处理器来说，读者可以在openocd的target目录找到并使用自己需要的目标配置文件：

在此给出STM32其他型号的命令供读者参考：

openocd.exe -f interface\cmsis-dap.cfg -f target\stm32f0x.cfg
openocd.exe -f interface\cmsis-dap.cfg -f target\stm32f1x.cfg
openocd.exe -f interface\cmsis-dap.cfg -f target\stm32f2x.cfg
openocd.exe -f interface\cmsis-dap.cfg -f target\stm32f3x.cfg

连接目标板成功后，我们需要在CubeIDE工程下新建调试配置以使用GDB服务，记得选择图中的GDB硬件调试配置去新建，选好工程和工程对应的elf文件：

在调试配置的Debugger中选择GDB软件（arm-none-eabi-gdb.exe），以及Openocd开启的调试服务端口：Localhost:3333，或者127.0.0.1:3333。

为了方便调试记得在main函数处设置个断点：

点击Debug调试，就可以如常进行运行和调试了：

通过External Tools调用Openocd

先在CubeIDE的External Tool中添加Openocd，依次进入CubeIDE菜单栏->RUN->External Tools-> External Tools Configrations->Program(右键)->NEW Configration,并根据自己喜好重命名：

在Debugger Configration中新建Launch Group并添加命令步骤：先执行Openocd，开启GDB服务,在使用arm-none-eabi-gdb执行调试：

此时就可以选择咱们自定义的Launch Group进行调试了。

本文参考资料：

在Stm32CubeIDE环境下使用DAP-Link仿真
通过External Tools在STM32CubeIDE下使用DAP-LINK
跟我一起学OpenOCD
手把手教你设计CPU-RISC-V处理器（胡振波）

*本文是作者闲时业余记录，如由遗漏错误，请见谅，感谢观看文章，转载不用注明出处。*