【Zephyr开发系列-7】Zephyr程序调试解析

1 概述

调试就是对CPU进行“暂停、检查、追踪、回放”去查找定位bug的过程。在VS Code中点击Debug开始，内部会执行非常多的步骤，有时候其中一个参数或步骤出错都会导致调试失败，这种很是让人抓狂，所以了解整个Debug建立流程很有必要。流程如下图（建议电脑观看）：

1.1 GDB client

简单来说，GDB client负责“理解程序”，常简称为GDB。GDB就是开发者真正操作的调试器，最常见的是交叉工具链里的 arm-zephyr-eabi-gdb。它负责读取zephyr.elf里的符号和调试信息，然后完成下断点、单步、查看变量、查看寄存器、查看调用栈这些动作。在上面VS Code链路里，cppdbg会启动GDB client，连接server后按launch.json里的 setupCommands 去执行 target remote、load、monitor reset之类的命令。

1.2 GDB server

GDB server负责GDB和板子之间的翻译。GDB 自己不会直接去操SWD/JTAG，也不会直接控制探针；它是通过GDB remote protocol连到server，再由server去驱动调试探针、访问目标板。最常见的GDB server/host tool有这些：

• OpenOCD：开源免费，支持很多 SoC，可以搭配多种调试器，但体系复杂排错成本较高。
• J-Link GDB Server：SEGGER提供，配合J-Link探针使用；GDB通过它去控制J-Link和目标板。
• pyOCD：Arm生态下开源GDB server，对CMSIS-DAP支持友好，主要适合Cortex-M调试。
• ST-LINK GDB Server：ST的官方GDB server，Zephyr支持通过west attach、west debug、west debugserver使用它。。
• Black Magic Probe：探针固件直接包含GDB server 功能，无需单独的host-tool程序。
  

1.3 runner

runner是west调试指令和调试工具之间的翻译。runner是west用来包装各种flash & debug host tool的适配层。runner 决定用哪套后端工具，并将参数翻译给J-Link/OpenOCD/pyOCD/ST-LINK，对应的GDB server再真正连板子。

1.3 west调试指令

Zephyr烧录调试界的总调度。
west flash：把固件烧进板子。
west debug：启动 GDB 调试，一般会连上调试服务器，必要时重新烧写 flash，然后进入一个调试器界面。
west debugserver：只启动调试服务器，等外部 GDB 来连接。
west attach：附加到已经在板子上跑的程序，不重新烧录，然后进入一个调试界面。

1.6 ELF文件

ELF不是单纯的“程序文件”，而是把机器码、内存布局、符号表、重定位信息、调试信息都装在一起的容器。在主机上调试时，GDB非常依赖ELF里的符号和调试信息。Zephyr构建系统会把这个文件生在build目录里，默认名字是zephyr.elf；如果CONFIG_KERNEL_BIN_NAME改了，那输出名也会跟着变。

1.7 launch.json文件

VS Code调试的配置文件。它告诉VS Code：要调哪个ELF、用哪个GDB、怎么启动debug server、连哪个端口、连上后执行哪些GDB命令。J-Link示例：

{"version":"0.2.0","configurations":[{"name":"Zephyr Workbench Debug [primary]","type":"cppdbg","request":"launch","cwd":"${workspaceFolder}","program":"${workspaceFolder}/build/primary/zephyr/zephyr.elf","args":[],"stopAtEntry":true,"svdPath":"C:\\ST\\STM32CubeCLT_1.21.0\\STMicroelectronics_CMSIS_SVD\\STM32H743.svd","environment":[],"externalConsole":false,"serverLaunchTimeout":30000,"filterStderr":true,"filterStdout":true,"serverStarted":"J-Link GDB server running on port 2331","MIMode":"gdb","miDebuggerPath":"${config:zephyr-workbench.sdk}\\gnu\\arm-zephyr-eabi\\bin\\arm-zephyr-eabi-gdb.exe","debugServerPath":"${workspaceFolder}/build/primary/.debug/west_wrapper.bat","debugServerArgs":"debugserver --build-dir \"${workspaceFolder}/build/primary\" --runner jlink --gdb-port 2331","setupCommands":[{"text":"-environment-cd ${workspaceFolder}/build/primary/zephyr"},{"text":"-target-select remote localhost:2331","description":"connect to target","ignoreFailures":false},{"text":"-file-exec-and-symbols zephyr.elf","description":"load file","ignoreFailures":false},{"text":"-interpreter-exec console \"monitor reset\"","ignoreFailures":false},{"text":"-target-download","description":"flash target","ignoreFailures":false},{"text":"set breakpoint pending on","description":"Set pending","ignoreFailures":false},{"text":"tbreak main","description":"Set a breakpoint at main","ignoreFailures":true}],"logging":{"moduleLoad":true,"trace":true,"engineLogging":true,"programOutput":true,"exceptions":true}}]}

2 调试工具选择

从前面介绍可知，烧录和调试并不是由某一个工具单独完成的，而是由一整套工具链配合完成。
Zephyr官方将主机端用于烧录、调试的工具称为Flash & Debug Host Tools。这些工具运行在电脑上，负责和调试器、开发板或Bootloader通信，完成程序下载、启动调试服务、连接GDB等操作。
而Debug Probe一般来说指的是调试探针或调试器或仿真器，它是一种专门的硬件，负责程序调试和烧录的硬件支撑。
不同工具支持的命令不完全一样，有些工具只适合特定厂商或特定芯片。以下主要围绕几种主流方案介绍，详细内容请参阅官方文档。

2.1 J-Link方案

J-Link是嵌入式领域最常见、最成熟的调试方案之一。它既可以指SEGGER的外置J-Link调试器，也可以指某些板载调试器刷入J-Link固件后的形态。常见硬件包括：

• J-Link EDU；
• J-Link PLUS；
• J-Link ULTRA+；
• J-Link PRO。

在Zephyr中，J-Link通常搭配J-Link Debug Host Tools使用，也可以在部分场景下配合OpenOCD使用。命令：

west flash-r jlink west debug-r jlink west debugserver-r jlink west attach-r jlink

SEGGER 提供的J-Link工具软件包含：

• J-Link GDB Server：用于GDB远程调试；
• J-Link Commander：用于命令行烧录和设备控制；
• RTT Viewer：用于查看 RTT 日志；
• SystemView：用于实时事件记录和分析。
  J-Link的优点是速度快、稳定性好、芯片支持范围广、生态成熟。缺点是正版价格比较高，个人用户成本较大。
  如果是商用项目，或者希望调试过程尽量省心，J-Link通常是非常稳妥的选择。

2.2 ST-LINK方案

ST-LINK是ST常见的调试器，广泛集成在STM32官方开发板上，也有独立的ST-LINK/V2、ST-LINK/V3、STLINK-V3PWR等硬件。
在Zephyr中，ST-LINK可以搭配多种软件使用：

• STM32CubeProgrammer；
• STM32CubeCLT；
• OpenOCD；
• J-Link Debug Host Tools。

其中，STM32CubeProgrammer 主要用于烧录：

west flash-r stm32cubeprogrammer

STM32CubeCLT 中包含 ST-LINK GDB Server，可以用于调试：

west debug-r stlink_gdbserver west debugserver-r stlink_gdbserver west attach-r stlink_gdbserver

也可以使用 OpenOCD：

west flash-r openocd west debug-r openocd

ST-LINK的优点是STM32官方支持好，很多开发板自带，不需要额外购买调试器，性价比很高。缺点是速度和高级调试能力通常不如J-Link，在OpenOCD下可能会遇到兼容问题。

2.3 DAPLink/CMSIS-DAP方案

DAPLink是基于CMSIS-DAP的开源调试方案，常见于Arm Cortex-M开发板。它通常不仅提供调试功能，还会同时提供：

• USB 虚拟串口；
• USB 大容量存储设备；
• 拖拽式烧录；
• CMSIS-DAP 调试接口。
  在 Zephyr中，DAPLink/CMSIS-DAP常搭配下面工具使用：
• pyOCD；
• OpenOCD；
• NXP LinkServer。

常见命令如下：

west flash-r pyocd west debug-r pyocd west flash-r openocd west debug-r openocd

2.4 NXP板载调试器方案

NXP很多开发板上会集成板载调试器。这类调试器通常由板子上的第二颗MCU实现，既可以负责调试，也可以提供USB转串口、拖拽烧录等功能。NXP常见板载调试器有三类：MCU-Link、LPC-Link2和OpenSDA。

1）MCU-Link：MCU-Link默认通常使用CMSIS-DAP固件，可以搭配NXP 的 LinkServer使用。

常用命令：

west flash-r linkserver west debug-r linkserver

MCU-Link也可以刷成J-Link固件，刷入后就可以走J-Link 工具链：

west flash-r jlink west debug-r jlink

2）LPC-Link2：支持多种固件有CMSIS-DAP、J-Link、DAPLink。官方推荐使用CMSIS-DAP固件配合 LinkServer。
3）OpenSDA：可以刷入不同固件有OpenSDA DAPLink、OpenSDA J-Link。
NXP方案的优点是和NXP官方生态结合紧密，尤其适合MCUXpresso、LPC、i.MX RT等开发环境。缺点是固件类型比较多，使用前要先确认板载调试器到底刷的是什么固件，否则Host Tool可能识别不到。

2.5 Black Magic Probe方案

Black Magic Probe是一个比较特殊的开源调试器。它把 GDB Server直接集成到了调试器固件中，所以不需要额外运行OpenOCD、J-Link GDB Server 或 pyOCD等GDB Server。
它的优点是开源、GDB 可以直接连接；缺点是芯片支持范围不如J-Link，生态不如J-Link/OpenOCD。

3 核心要点

• 知道工具之间的关系。
• 会改配置，知道为什么这么改。
• 碎片知识拼成完整调试链路。