Cortex-Debug是STM32硬件调试首选插件，因其唯一稳定支持J-Link、ST-LINK、OpenOCD三类调试器，并原生支持SWO输出、RTOS线程识别和多核同步，而其他插件仅支持单一调试器或缺乏实时寄存器/内存刷新能力。
为什么Cortex-Debug是STM32硬件调试的首选插件
因为它是目前VSCode生态中唯一能稳定对接J-Link、ST-LINK、OpenOCD三类调试器，并原生支持SWO输出、RTOS线程识别和多核同步的调试扩展。其他插件要么只支持单一调试器（如ST-Link Debugger仅限ST芯片），要么缺少寄存器/内存实时刷新能力。
常见错误现象：Cortex-Debug 启动后报错 No device found，多数是因为JLinkGDBServerCL.exe未加入环境变量，或servertype配置与实际硬件不匹配。
- 使用场景：STM32F1/F4/H7全系列、NXP i.MX RT、RISC-V（需额外配置）
- 参数差异：
"servertype": "jlink"要求已安装J-Link软件包；"servertype": "openocd"则依赖openocd命令在PATH中可执行 - 性能影响：启用
svdFile路径后，寄存器视图加载变慢但值解析更准；关闭则响应快但寄存器名显示为0x40021000这类地址
Digital-IDE插件不是调试器，但能补足硬件开发闭环
它不直接连接JTAG/SWD，而是把Verilog/VHDL仿真、波形查看（VCD）、网表渲染集成进VSCode界面。如果你在写FPGA逻辑并用ModelSim仿真，Digital-IDE能让你跳过外部波形窗口，在编辑器里拖拽信号、切进制、标时序点。
容易踩的坑：iverilog作为默认linter，对SystemVerilog语法支持有限；若项目含class或interface，必须切换到verilator或vivado后端，否则Digital-IDE会静默跳过语法检查。
- 使用场景：数字电路设计、FPGA原型验证、SoC模块级测试
- 兼容性注意：macOS上
ModelSim路径需手动填入digital-ide.simulatorPath，不能依赖自动发现 - 性能影响：开启Wavedrom注释渲染后，大文件打开延迟明显；建议仅在顶层模块保留
/// @wave块
launch.json里executable路径写错，调试根本不会启动
这是最常被忽略的硬性前提——Cortex-Debug不编译，只加载ELF文件。如果"executable": "${workspaceFolder}/build/firmware.elf"指向不存在的路径，VSCode连GDB Server都不会拉起，控制台只显示Failed to launch GDB，没有进一步提示。
实操建议：
- 确认构建产物路径：STM32CubeMX生成的Makefile默认输出在
Build/，而CMake可能在build/或out/，大小写也敏感 - 用绝对路径临时验证：把
${workspaceFolder}替换成完整路径（如/home/user/project/build/firmware.elf），排除变量解析问题 - 检查ELF有效性：
file firmware.elf应返回ARM aarch32 executable；若显示data或not recognized，说明链接失败或格式错误
DeepSeek插件不能替代硬件调试，但能加速调试逻辑设计
它无法读取寄存器、触发断点或烧录Flash，但在写调试逻辑时很有用：比如你卡在UART收不到数据，让它分析HAL_UART_Receive_IT调用链，或根据错误日志生成printf定位建议。它的价值在于缩短“猜问题”时间，而非执行调试动作。
关键限制：
- 不理解
__attribute__((section(".isr_vector")))这类底层修饰，可能误判中断向量表定义错误 - 对CMSIS头文件中的位域宏（如
__IOM uint32_t CTRL）解析不准，补全时易推荐错误字段名 - 若项目含自定义
startup_stm32f4xx.s汇编启动文件，它基本无法提供有效上下文
真正复杂的地方在于调试器链路本身：J-Link固件版本、SWD线长、目标板供电稳定性，这些物理层问题，再强的插件也无能为力。代码写得再好，线没接稳，Cortex-Debug照样连不上。
