Cortex-Debug 是 VS Code 专属插件，无法用于 Sublime Text，因其深度依赖 VS Code 的 DAP 协议、扩展主机和调试 UI 机制，而 Sublime 既无 DAP 客户端能力，也无对应调试基础设施。
Sublime Text 本身不支持 Cortex-Debug —— 这个插件是 VS Code 的专属调试扩展，无法在 Sublime 中安装或运行。
为什么 Cortex-Debug 不能用在 Sublime Text 上
Cortex-Debug 是基于 VS Code 的 Debug Adapter Protocol（DAP）实现的，深度依赖 VS Code 的扩展主机、调试服务和 UI 集成机制。Sublime Text 没有 DAP 客户端能力，也不提供 package.json 扩展生命周期、launch.json 解析器或调试视图面板。
常见误解来源：
– 搜索 “sublime cortex debug” 时出现的旧博客常把 sublime-gdb 或 sublime-build-system 配置误标为 “Cortex-Debug”；
– 有人将 OpenOCD + GDB 命令行流程套用到 Sublime 构建系统，误以为等价于图形化调试。
- VS Code 的
cortex-debug扩展会自动启动openocd、注入gdb-server、解析.elf符号、支持断点/变量监视/寄存器查看/RTOS 线程切换 - Sublime 只能通过
sublime-build-system调用arm-none-eabi-gdb执行命令行调试（无 UI、无断点图形反馈、无变量树） - 没有插件能桥接 Sublime 和 DAP 协议 —— 目前没有任何活跃项目提供该能力
Sublime 中替代调试的可行方案
如果你坚持使用 Sublime 作为编辑器，可搭配外部工具链实现基础调试流，但需接受功能降级：
- 用
sublime-build-system启动openocd（后台运行），再手动在终端中执行arm-none-eabi-gdb加载.elf并target remote :3333 - 配置 Sublime 构建系统调用
gdb的-ex参数批量执行命令（如-ex "b main" -ex "c"），适合单步验证，不适合交互调试 - 用
sublime-gdb插件（已多年未更新）—— 仅支持基本命令输入和输出窗口，不解析源码行、不支持断点图标、GDB 版本兼容性差（尤其对arm-none-eabi-gdb 12+的 MI2 输出格式失效） - 推荐组合：Sublime 写代码 + VS Code（最小窗口停靠）做调试 —— 两者共享同一工程目录，无需同步文件
真正想用 Cortex-Debug？必须换编辑器
这不是配置问题，而是平台能力边界问题。Cortex-Debug 的核心价值（比如 SWO 输出解析、Core Register 视图、FreeRTOS thread awareness、SVD 寄存器映射）全部构建在 VS Code 的扩展 API 之上。
如果你已在 Sublime 中重度定制了快捷键、侧边栏插件或 Snippet，迁移成本确实存在，但调试体验差距太大：
- 在 VS Code 中，点击函数名按
F9就设断点，悬停看变量值，Ctrl+Shift+P输入Cortex-Debug: Restart Session一键重连 - 在 Sublime 中，你得记住
monitor reset halt、load、stepi等 GDB 命令，且每次修改代码后要手动 reload symbol - RTOS 线程列表、内存视图、外设寄存器展开这些功能，在 Sublime 下完全不可见
硬要在 Sublime 里“模拟”，只会陷入不断补丁的状态，最后发现花三天配环境的时间，足够在 VS Code 里跑通十个不同芯片的调试配置了。
如果仍想试 Sublime + GDB 基础调试
以下是最简可用的构建系统示例（假设已安装 openocd 和 arm-none-eabi-gdb）：
{
"cmd": ["arm-none-eabi-gdb", "-q", "$file_path/${file_base_name}.elf"],
"shell": true,
"working_dir": "$file_path",
"variants": [
{
"name": "Debug",
"cmd": ["arm-none-eabi-gdb", "-q", "$file_path/${file_base_name}.elf", "-ex", "target remote :3333", "-ex", "monitor reset halt", "-ex", "load", "-ex", "c"]
}
]
}
注意：
– 必须提前在另一个终端运行 openocd -f interface/stlink.cfg -f target/stm32f4x.cfg
– -ex "c" 会让程序直接运行，无法暂停在 main；建议先去掉，手动输入 b main 再 c
– arm-none-eabi-gdb 输出默认是 TUI 模式，在 Sublime 构建面板里会乱码，实际不可用；只能靠纯命令行反馈
真正的嵌入式调试不是“能连上就行”，而是“信息是否可读、操作是否可逆、状态是否可视”。这些，Sublime 当前生态做不到，也没人正在做。
