IDE/基于VSCode搭建STM32集成开发环境 / Cortex-debug插件工作原理和使用方法（含3种JLink烧录方案）

文章目录

• 概述
• VSCode调试体系
• • 调试运行界面
  • DAP 调试适配器协议
  • VSCode 调试框架/生态
  • Cortex-Debug 角色定义
  • Cortex-Debug 安装
• GDB调试
• • GDB 客户端
  • GDB 服务端
  • GDB服务是定制的
  • OpenOCD
• 插件依托的配置
• • 设置 settings.json
  • 设置 launch.json
• VSCode下的JLink烧录
• • Cortex-Debug 直接下载
  • LiteOS Studio 的调试插件
  • 创建独立烧录任务
  • make download/扩展Makefile
  • 烧录方式选择
  • Cortex-Debug自动烧录？
• 调试运行中

概述

针对在VSCode下开发和直接调试嵌入式程序的需求，本文详细探讨了常用编译和调试插件 Cortex-debug 的工作机制和使用方法。基于VSCode + GCC + Cortex-debug 组合的集成开发环境广泛适用于ARM Cortex 嵌入式程序开发、编译和调试过程。该IDE也适用于基于LiteOS 的物联网端侧程序开发，可用于替换老旧的 LiteOS Studio 开发环境，这也是我的初衷。

@NOTE
转载请标明出处 ，https://blog.csdn.net/quguanxin/category_12929470.html
@HISTORY
在整理 ## 时，文章太长了，因此拆出来此文。

VSCode调试体系

Visual Studio Code 的调试体系是一个高度模块化协议驱动的架构，其核心设计思想是通过标准化协议解耦调试前端与后端，实现跨语言和跨平台的通用调试能力。VSCode 提供通用调试界面和基础管理能力，由其插件实现DAP协议与底层调试协议的转换。

调试运行界面

即使你什么插件都没有安装过，VSCode 也会有调试按钮、运行和调试卡，如下左图展示。调试过程中使用的工具条（单步、连续、停止…），也应该是 VSCode 本体的。若被打开的文件夹下没有 launch.json 文件，则调试卡如下图左侧视图。

当我们点击以上左侧视图中的 “运行和调试” 按钮后，会弹出右侧视图中的下拉列表。若已经安装了 Cortex-Debug 插件，则在调试器类型选择列表中就会有其选项，如上图。理论上选择一个调试器类型后，支持自动生成一个 launch.json 文件。若自动生成过程出现错误，则需要点击上图左侧视图绿色线标记的 “自定义创建 launch.json文件” 以完成手动创建。如果你 VSCode 中安装了AI编程插件，这个通常也会自动生成，当然你也可以参考其他说明来手敲进去。一旦你生成了launch.json文件，则调试界面将变为，

理论上，通过对launch.json的合理编写，可创建多个调试器，如，针对Cortex-Debug插件调试器类型的、针对Python调试器类型的、针对JavaScript/Node.js 调试器类型的、针对芯片类型A的、针对芯片类型B的、针对JLink的、针对STLink的…

DAP 调试适配器协议

调试适配器协议 （Debug Adapter Protocol，DAP）
是一种标准化抽象协议，用于解耦开发工具（如 IDE编辑器）与底层调试器的交互。她由 Microsoft 主导设计，最初为 Visual Studio Code 的调试架构服务，目的是解决多语言调试器集成时的重复适配问题。与 LSP（Language Server Protocol） 和 BSP（Build Server Protocol） 类似，DAP 旨在通过协议统一功能性差异，减少开发工具的适配成本。尽管由微软推动，但 DAP 被设计为独立于 VSCode 的开放规范，协议文档和实现均开源，鼓励跨工具应用，志在成为行业标准。

因为亲生，VSCode 内置支持DAP，其他IDE通常要要通过插件支持。DAP 与 HTTP 协议结构类似，分为头部（ASCII 编码）和内容（UTF-8 JSON），有请求/响应/事件等类型。DAP 的核心设计目标是标准化调试操作，其功能覆盖调试全生命周期。

要特别明确的一点是，DAP适配器不替代GDB，而是将其能力标准化为统一接口 。在如上大致理解了DAP的含义后，我们继续深入。

VSCode 调试框架/生态

在 VSCode 的调试生态系统中，调试框架分为三层，DAP 作为 “中间翻译层” ，将 IDE 的调试界面与各种调试后端连接起来。按照这个说辞，一个比较片面的理解是，IDE中与调试有关的UI应该算是前端，而GDB无论是客户端或服务端，都归属于后端。可以通过 DAP 对接到VSCode的GDB后端，也可以是其他 “后端”，即其他调试器类型，它们可能包括如：
*CDB (Microsoft Visual C++ Debugger) ，*Windows 平台上的原生调试器，用于调试 C、C++、C# 等语言。
*Node.js/V8 调试器，*调试 JavaScript 和 TypeScript 代码。VSCode 内置，通过 node-debug2 适配器实现 DAP 通信。
LLDB (Low Level Debugger)、Python 调试器、Java 调试器、Rust 调试器、Go 调试器、.NET 调试器…

按照上述说辞，各层次的主要参与者和核心功能的一个描述如下，（可能不全合理）…

Cortex-Debug 角色定义

以Cortex-Debug为例，我们已经大致理解了其在VSCode体系下的作用。其主要功能包，协议转换、硬件抽象、添加 Cortex嵌入式软件调试的专属功能三个方面。通过这种架构，Cortex-Debug 在协议层解决了嵌入式调试的特殊需求，使 VSCode 能像调试 Python 或 Node.js 一样流畅地调试 STM32 等微控制器，同时保持硬件实现的灵活性。以读取目标芯片某寄存器值的调试过程为例，

插件 Cortex-Debug 是指挥官不是执行者，负责编排调试流程。
在整个执行过程中，它首先读取 launch.json 中的 executable（ELF 文件路径）、servertype（J-Link/OpenOCD 等）、device（芯片型号）等参数，将 VSCode 的DAP信息翻译为GDB指令 。然后，调用 GDB 客户端加载程序，并向 GDB 服务器发送调试指令（如复位擦除写入），这与我们在命令行终端中调用本质没有区别。最后，解析 GDB 响应输出并更新至调试器变量视图、外设寄存器视图等。

Cortex-Debug 安装

Cortex-Debug 是 Visual Studio Code 的一款专业插件，专为 ARM Cortex-M 系列微控制器 的调试而设计。它通过集成 GDB 调试器和多种硬件调试服务器（如 OpenOCD、J-Link），为嵌入式开发者提供高效、可视化的调试环境。其依赖于其他4款插件。

GDB调试

在VSCode的调试体系下，无论是GDB客户端还GDB服务端，它们都归属于后端。

GDB 客户端

在基于ARM-GCC工具链的嵌入式集成开发环境中，所谓的 GDB客户端就是 arm-none-eabi-gdb.exe 执行程序。它是专为 ARM Cortex-M/R/A 架构设计的 GDB 调试器客户端。它运行在开发主机（如 Windows/Linux）上，负责解析调试命令管理符号表（如 ELF 文件中的函数/变量地址）并与本地或远程的 GDB Server 通信。其名称的含义解释如下，
arm: 目标架构为 ARM
none: 无供应商限制
eabi: 遵循嵌入式应用二进制接口规范（Embedded Application Binary Interface）
gdb: GNU 调试器

arm-none-eabi-gdb 主要工作任务：
通过 target remote 命令连接GDB服务器（default-TCP:2331），作为协议中转站，将GDB/MI指令转发至服务端，并接收响应数据。客户端会解析编译生成的ELF文件，提取符号表、函数地址、变量类型等调试信息。建立源码行号↔机器地址的映射关系，实现源码级调试（如break main在main()函数首行设断点）。将用户输入的命令转换为标准化GDB/MI（Machine Interface）协议指令。此外客户端还负责调试状态维护，如跟踪当前程序状态（运行/暂停）、寄存器值、堆栈帧位置，缓存所有有效断点地址，同步至服务端。

GDB 服务端

在 SEGGER J-Link 软件包中，JLinkGDBServer和JLinkGDBServerCL是两个功能相同但交互方式不同的程序。

两者均可以作为GDB远程调试服务器，通过TCP/IP协议（默认端口2331）桥接GDB调试器客户端与J-Link硬件，实现代码下载、断点调试和寄存器监控等功能。两者只在界面形式上有差异，CL应该是 CommandLine 命令行工具的含义。

以Jlink为例，其 GDB Server 有两种运行模式，
传统模式（更常见） GDB客户端 → J-Link GDB Server(主机程序) → J-Link硬件 → 目标设备。
简化模式（某些嵌入式设备支持） GDB客户端 → J-Link硬件(内置GDB Server功能) → 目标设备。
在传统模式下，J-Link GDB Server 是主机上的可执行程序（如JLinkGDBServerCL.exe），通过 USB 与 J-Link 硬件通信，适合复杂调试场景，如多线程、复杂断点。在简化模式下，主机客户端直接连接J-Link 固件中集成的 GDB Server通信，但其功能是受限的。

GDB客户端和服务端之间通过 GDB Remote Serial Protocol 进行通信，这是一种基于TCP/IP的文本协议。服务端会监听TCP端口（如gdbserver :1234 ./test），等待客户端连接，可能是远程的不在同一个主机上的客户端哦。GDB服务端主要功能：

GDB服务是定制的

在嵌入式调试架构中，GDB客户端是通用的，与硬件无关的。而GDB服务端需要针对不同的硬件调试器进行深度定制，如JLinkGDBServer (J-Link专属)、st-util (ST-Link专用)、openocd (开源多适配，可以支持JLink和STLink等)。GDB服务端的定制化必要性主要来自，

OpenOCD

OpenOCD（Open On-Chip Debugger） 可以粗浅的认为它是一种带有通用的GDBServer实现。它是一个开源片上调试器软件，核心功能是为嵌入式芯片提供调试烧录和边界扫描支持，其实现了GDB远程串行协议（GDB RSP），因此可作为GDB的服务端。除实现标准GDB协议外，OpenOCD还提供独立烧录、Telnet控制（端口4444）等功能。其核心架构和工作原理如下：

OpenOCD核心功能，这里不再细究，但其地位是不可撼动的。OpenOCD采用GPL许可证，允许免费使用和修改源码，适配自定义硬件，无需硬件授权费用，大幅降低嵌入式调试门槛。J-Link GDB Server 是 SEGGER 官方提供的免费软件，但必须搭配正版 J-Link 或 J-Trace 调试器硬件使用，而正版 Jlink 价格从几百到上万的都有，硬件购买时一次性支付，后续软件升级免费。

插件依托的配置

Cortex-Debug的运行是依托于ARM-GCC工具链的，关于make工具gcc工具的安装，这里不再赘述。

设置 settings.json

在VSCode设置界面中，搜索Cortex-debug，并配置如下内容，

配置后，将在 E:\\Test\\F427_GCC.vscode\\settings.json 文件中，生成与 cortex-debug 插件相关的如下内容，

 \"cortex-debug.armToolchainPath\": \"D:\\\\IDE_IoT\\\\gcc-arm-none-eabi-10.3\\\\bin\", \"cortex-debug.gdbPath\": \"D:\\\\IDE_IoT\\\\gcc-arm-none-eabi-10.3\\\\bin\\\\arm-none-eabi-gdb.exe\", \"cortex-debug.JLinkGDBServerPath\": \"C:\\\\Program Files (x86)\\\\SEGGER\\\\JLink\\\\JLinkGDBServerCL.exe\"

@NOTE 过程问题QA，找不到gdb可执行程序

通过 Cortex-Debug 日志（showDevDebugOutput: true）定位具体原因。最终发现，上述错误是gdb文件路径配置错误导致的。在E:\\Test\\F427_GCC.vscode\\settings.json配置中gdbPath，应该设置为文件路径而不是文件夹路径。

//gcc配置文件夹路径\"cortex-debug.armToolchainPath\": \"D:\\\\IDE_IoT\\\\gcc-arm-none-eabi-10.3\\\\bin\",//gdb记得要配置文件路径，而不是文件夹路径\"cortex-debug.gdbPath\": \"D:\\\\IDE_IoT\\\\gcc-arm-none-eabi-10.3\\\\bin\\\\arm-none-eabi-gdb.exe\",

设置 launch.json

launch.json 是 VSCode 调试配置的中枢文件，其主要功能如下：
调试会话定义
配置调试器启动参数（GDB路径、服务端连接等）
指定调试模式（启动新进程/附加到现有进程）
管理多调试配置（开发/测试/生产环境切换）
硬件交互控制
配置嵌入式调试参数（芯片型号、接口速度）
定义烧录前/后执行命令序列（复位、擦除Flash）
管理调试器生命周期（启动/终止GDB服务端）
环境集成
关联源码与调试符号
配置外设寄存器视图（SVD文件）
集成实时数据传输（RTT/SWO输出）
工作流自动化
调试前自动编译（衔接tasks.json）
条件断点/观察点设置
自定义变量格式化显示

以Cortex-Debug 为例，基础配置项，

以Cortex-Debug 为例，硬件交互配置项，

以Cortex-Debug 为例，高级调试配置项，

以Cortex-Debug 为例，服务端管理配置项，

时间有限，这块不再继续展开。 launch.json 绝对是功能灵活且强大的存在。

VSCode下的JLink烧录

本章会实践3种基于Jlink的嵌入式程序烧录方式，包含Cortex-Debug烧录方式，并额外说明其自动化机制。

Cortex-Debug 直接下载

该方案依赖于 launch.json 中的如下配置，

{ //see more, https://go.microsoft.com/fwlink/?linkid=830387 \"version\": \"0.2.0\", \"configurations\": [ { \"cwd\": \"${workspaceFolder}\", \"name\": \"Debug with JLink\", \"type\": \"cortex-debug\", \"servertype\": \"jlink\", \"device\": \"STM32F427ZITx\", \"executable\": \"./build/F427_GCC.elf\", \"request\": \"launch\", \"runToEntryPoint\": \"main\", \"showDevDebugOutput\": \"none\", \"interface\": \"swd\" //\"preLaunchTask\": \"Build Project\" // 可选/烧录前编译/后文有讲 } ]}

有些资料中提及要在launch.json中附加 postLaunchCommands 等参数配置才可以实现调试前的自动下载，不要轻信，若遇到问题慢慢分析。实际上仅使用前文的配置内容，在调试启动的时候，新程序就会自动的灌输到主板中。

LiteOS Studio 的调试插件

在使用 LiteOS Studio 的过程中，就见识过 launch.json 文件，那个时候还感觉它是天书般的存在。我们倒回头来看看。我们使用 LiteOS Studio 打开 LiteOS_Lab_HCIP 工程。进行工程配置界面，完成目标板卡配置操作后，launch.json文件就会生成，并写入除了[executable-调试文件路径] 配置项之外的全部内容。全配置下的一个文件如下，

{ \"version\": \"0.2.0\", // 配置文件版本 \"configurations\": [ { \"name\": \"Jlink Debug\",  // 调试会话名称（显示在VSCode调试下拉菜单） \"cwd\": \"${workspaceRoot}\", // 工作目录（设为当前工程根目录）//即E:\\\\LiteOS_Lab_HCIP \"executable\": \"E:\\\\LiteOS_Lab_HCIP\\\\targets\\\\STM32L431_BearPi\\\\GCC\\\\build\\\\Huawei_LiteOS.elf\", // 目标固件路径 \"request\": \"launch\", // 启动模式（launch=重新加载程序，attach=附加到已运行程序）//有此配置界面 \"type\": \"liteos-studio-debug\", // 调试器类型（华为LiteOS专用调试插件） \"servertype\": \"jlink\",  // 底层调试服务器类型（J-Link） \"device\": \"STM32L431RC\", // 目标芯片型号 \"showDisassemble\": true, // 调试时显示反汇编代码 \"interface\": \"swd\",  // 调试接口协议（SWD两线制） \"postLaunchCommands\": [ // 调试启动后自动执行的GDB命令 \"delete\", // 删除所有断点 \"b main\", // 在main函数开头设置断点 \"monitor reset halt\",  // 复位芯片并暂停 \"continue\"// 继续运行到断点处停止 ] } ]}

在 LiteOS Studio 开发环境下，点击下载按钮执行实验5的程序的下载，

创建独立烧录任务

要开始使用任务运行器，首先需要在.vscode文件夹中创建tasks.json文件。可以通过访问VSCode顶部菜单栏中的Terminal -> Configure Tasks，选择Create tasks.json file的选项来启动创建。VSCode将提供一系列预定义的任务配置模板供选择，比如Others可以创建一个自定义任务的基础模板。然后在tasks.json文件其中添加如下已实测验证过的配置，

{ // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format \"version\": \"2.0.0\", \"tasks\": [ { \"label\": \"Dahe Flash Firmware\", \"type\": \"shell\", \"command\": \"JLink.exe\", \"args\": [ \"-device\", \"STM32F427ZITx\", \"-if\", \"swd\", \"-speed\", \"4000\", \"-autoconnect\", \"1\", \"-commandfile\",  \"\\\"${workspaceFolder}/flash.jlink\\\"\" //双引号强制路径作为整体传递 ], \"problemMatcher\": [], \"group\": { \"kind\": \"build\", \"isDefault\": true }, \"presentation\": {  // 优化输出显示 \"echo\": true, \"reveal\": \"always\", \"focus\": false, \"panel\": \"dedicated\", \"showReuseMessage\": false // 避免\"终端被覆盖\"提示 } } // task { ] //task [}

JLink.exe 所在路径（JLink驱动路径），要确保在环境变量中可以找到。flash.jlink 是 J-Link Commander 的脚本文件，用于自动化执行 Flash 烧录、擦除、复位等操作。它通常与 tasks.json 或命令行工具（如 JLink.exe）配合使用，实现一键烧录。在工程根目录下创建 flash.jlink 文件，内容如下，

halt // 暂停 CPU//unlock kinetis // bakerase  //全Flash擦除//加载bin/hex到指定的地址 /不识别elfloadfile ./build/F427_GCC.hex 0x08000000 r  // 复位芯片sleep 10 // 延时确保复位稳定 /可能不需要g  // 运行程序 exit // 退出

在定义了任务后，就可以通过不同的方式来运行它们。可以通过按下F1或Ctrl+Shift+P打开命令面板、输入Tasks: Run Task并选择所需的任务来手动运行任务。然后在弹出的下拉任务下拉列表中选择我们的自定义任务。

任务运行器是一个非常有用的工具，能够在VSCode中执行常见任务、构建项目和管理工作流程。在VSCode中使用任务运行器的方法包括：创建任务配置文件、定义任务、运行和调试任务、自定义快捷键、集成外部命令和工具，以及使用预定义任务。

此执行结果：下载成功，通过串口监控可看到新程序自动开始运行。

@NOTE问题和解决方案，无法识别 J-Link Command File。

\"-commandfile\", \"${workspaceFolder}/flash.jlink\"//上述配置被识别为错误Could not open J-Link Command File \'E:TestF427_GCC/flash.jlink\'//以下几种格式也不行 \"${workspaceFolder}\\\\flash.jlink\" \"..\\\\flash.jlink\" \"E:\\\\Test\\\\F427_GCC\\\\flash.jlink\" //实验成功的配置方案 /双引号强制路径作为整体传递-兼容正斜杠\"-commandfile\", \"\\\"E:\\\\Test\\\\F427_GCC\\\\flash.jlink\\\"\"//也可以的 \"\\\"${workspaceFolder}/flash.jlink\\\"\"

@NOTE问题和解决方案，烧录不报错，但程序却没有被更新。
在最初的时候，flash.jlink 文件中没有编写 erase 操作，导致新程序无法写入Flash中，但此时没有看到明显报错。

@NOTE问题和解决方案，烧录过程的擦除时间太长。

前文脚本内容中的 erase 操作时擦除的整个Flash区域，耗时超过30s时间。我尝试使用以下方式，只擦除程序空间，

//从Flash起始地址开始的256k空间/即1-5扇区/按长度擦除时要加逗号 erase 0x08000000, 0x40000 

不过很遗憾，上述这些个方案，似乎都没有生效，擦除过程始终是30s以上，同样程序MDK烧录过程仅4s左右。也尝试烧录 bin类型文件、提升JLink工作速率从4000到10000 等方案，都没有效果。运行任务后，会弹出JLink的工作小窗口，通过其状态栏的显示信息，可以确定无论我使用了怎样格式的erase指令，每次烧录都是在擦除全部Flash，是耗时的根本原因。
截止20250618，次问题尚未解决，临时关闭。20250620，找到一个解决方案，缩短烧录时间至8s左右。修改脚本如下，

halt // 暂停 CPU//unlock kinetis // bak//解锁Flash控制器w4 0x40023C04 0x45670123 // 写入KEY1w4 0x40023C04 0xCDEF89AB // 写入KEY2// 清除所有挂起标志w4 0x40023C08 0x0000003C// 禁用自动擦除w4 0x40023C0C 0x00000001//擦除256K空间erase 0x08000000 0x0803FFFF//加载bin/hex到指定的地址loadfile ./build/F427_GCC.bin 0x08000000 r  // 复位芯片sleep 10 // 延时确保复位稳定 /可能不需要g  // 运行程序 exit // 退出

我的原脚本中虽然指定了部分擦除，但可能存在如下问题：
1、如果 Flash 控制器未正确解锁，后续的擦除命令可能被忽略或执行默认擦除。
2、STM32F4 的loadfile命令默认会触发自动擦除，可能覆盖你之前的部分擦除设。
上述解决方案的工作原理如下：
w4：J-Link 脚本命令，表示 “write 4 bytes”。0x40023C04地址是 STM32F427芯片Flash控制器的FLASH_KEYR寄存器地址。STM32F4 的 Flash 控制器默认处于保护状态，需要按顺序写入两个特定的解锁键值才能启用写/擦除操作。
0x40023C0C 地址是 STM32F427芯片Flash控制器的FLASH_OPTCR寄存器地址。写入0x00000001是将OPTCR寄存器的nPRG位置1，表示禁用自动擦除。STM32F4 的 Flash 控制器在某些情况下会自动执行擦除操作（如写入新数据时），通过设置nPRG位可以禁止这种自动行为，让擦除操作完全由用户控制

make download/扩展Makefile

该种方案是小熊派社区示例程序使用说明中提及的烧录方案。小熊派示例程序使用的是 stlink+openocd 方案，

# downloadOPENOCD_INTERFACE = stlink-v2-1.cfgOPENOCD_TARGET = stm32l4x.cfgOPENOCD_FLASH_START = 0x08000000download:openocd -f $(SDK_DIR)/tools/openocd/$(OPENOCD_INTERFACE) -f $(SDK_DIR)/tools/openocd/$(OPENOCD_TARGET) -c init -c targets -c \"reset halt\" -c \"flash write_image erase ./$(BUILD_DIR)/$(TARGET).bin 0x08000000\" -c \"verify_image ./$(BUILD_DIR)/$(TARGET).bin 0x08000000 bin\" -c \"reset run\" -c shutdown

使用JLINK调试工具时，配置会简单些。该种方案在本质上与上一节中使用的 “独立任务” 方案是一致的，即命令行工具带参数调用。在 Makefile 中新增 download 目标，调用 J-Link 命令行工具完成烧录。脚本flash.jlink文件可以复用。

######################################## download 大河.qu######################################## 添加烧录工具路径（根据实际安装位置调整）JLINK_EXE ?= \"C:\\\\Program Files (x86)\\\\SEGGER\\JLink\\\\JLink.exe\"# 定义烧录目标download:$(JLINK_EXE) -device STM32F427ZITx -if SWD -speed 4000 -CommanderScript ./flash.jlink

烧录过程和烧录现象与方案2一致，不再赘述。

烧录方式选择

上述几种方案的一个简单比较，

在开发调试阶段使用方案一描述的烧录方法是比较称心如意的，速率也挺快的。基于 flash.jlink 脚本的方案，还需要进一步打磨。

Cortex-Debug自动烧录？

在启动 Cortex-Debug 调试运行的过程中，程序被自动的下载到了目标主板中。我一开始并没有觉得奇怪，但当我研究完后两种烧录方案后，我却有点蒙了。后两种方案都是直接依赖于 Jlink 驱动下执行程序和脚本参数的，但在我们并没有为Cortex-Debug自动烧录过程提供过类似的配置啊，那么，Cortex-Debug 是如何做到的呢？

Cortex-Debug 在调试启动时自动下载程序，本质是通过 预置命令序列 调用 GDB 的 load 功能。有的资料中提及要在preLaunchCommands配置load过程，但在实践中，即使我没有配置 preLaunchCommands 启动后的执行命令，也是可以触发调试运行前的烧录过程的。

Cortex-Debug 的自动下载功能本质是通过调用 GDB 工具链内置的 Flash 编程能力实现的，而非其独立实现的功能。这里，Cortex-Debug 的充当的是流程编排者的角色。Cortex-Debug 通过配置调用 GDB 命令实现自动下载，本质是封装了底层操作：

烧录过程的详细步骤，可能是这样的，

在另外两种烧录方案 “创建独立烧录任务” 和 “Makefile / make download” 中，它们都依赖于Jlink驱动中的 JLink.exe 的直接调用。而 Cortex-Debug 触发的烧录过程我不确定是否有调用 JLink.exe 可执行程序，实际情况是怎样的呢？
这个地方不要想偏了哈，Jlink.exe（J-Link Commander）与JLinkGDBServer之间不会直接通信。二者是独立的工具，分别服务于不同的调试场景，并通过不同的方式与J-Link硬件交互。JLinkGDBServer 就得老老实实通过GDB客户端来访问。

总之，Cortex-Debug 烧录是基于GDB体系的，而方案2和3烧录过程，它们与直接使用Jlink驱动下的JFlash工具程序本质一样。

调试运行中

在VSCode的launch.json文件配置保存后，就可以看到如下调试启动按钮。

调试启动成功，程序在main函数断住，我们熟悉的样子，