第2章 调试环境搭建：硬件调试工具（JTAG、逻辑分析仪）、软件调试工具（GDB、kdump、ftrace）、环境配置实战

调试环境搭建，是驱动稳定性工作的第一步，也是最容易被忽视的一步。

我见过太多工程师，上来就对着代码硬啃，结果出了问题连基本的寄存器值都读不出来。说白了，工具没准备好，你就是在盲人摸象。

2.1 硬件调试工具：JTAG与逻辑分析仪

硬件调试工具，是驱动开发者的「眼睛」。没有它们，你根本不知道芯片内部发生了什么。

2.1.1 JTAG调试器

JTAG，全称Joint Test Action Group，是一种边界扫描技术。它允许你直接访问CPU的内部寄存器、内存和外设。

我个人习惯用SEGGER J-Link和ARM DAPLink。为什么？因为它们稳定，而且支持断点、单步执行、变量查看这些基本操作。

核心功能：

  • 断点调试：在代码中设置断点，观察程序执行流程
  • 寄存器读写：直接查看和修改CPU寄存器值
  • 内存访问：读取或写入任意内存地址
  • Flash编程：烧录固件到目标设备

嗯，这里要注意：JTAG连接线不能太长，否则信号容易失真。我建议控制在15厘米以内。

避坑指南：

我曾经在一个项目中，JTAG死活连不上目标板。查了半天，原来是调试接口的复位引脚没拉高。记住，JTAG的nTRST和nSRST引脚，一定要接对电平。

2.1.2 逻辑分析仪

逻辑分析仪，是用来观察数字信号时序的。驱动开发中，它主要用于分析GPIO、SPI、I2C、UART等接口的波形。

你想想看，当你的SPI驱动读写数据不对时，用逻辑分析仪抓一下CLK、MOSI、MISO的波形，问题一目了然。

我推荐入门级用Saleae Logic Analyzer，采样率24MHz，够用了。高级项目可以考虑Keysight或Tektronix的型号。

工具 适用场景 采样率要求 价格区间
Saleae Logic 8 GPIO、I2C、SPI、UART 24MHz ¥300-500
Keysight 16864A 高速总线、DDR、PCIe 1GHz+ ¥5万+
Tektronix MSO58 混合信号、复杂协议 500MHz+ ¥8万+

个人经验：

抓取I2C波形时，记得把触发条件设为START条件。否则你会抓到一堆无意义的空闲电平。我曾经因为这个浪费了整整一个下午。

2.2 软件调试工具：GDB、kdump、ftrace

软件调试工具，是驱动开发者的「手术刀」。它们能帮你深入内核，找到问题的根源。

2.2.1 GDB调试器

GDB，GNU Debugger，是Linux下最常用的调试工具。它支持用户态和内核态调试。

说白了，GDB就是让你能在代码里「慢动作回放」。你可以设置断点、查看变量、单步执行，甚至修改内存。

我常用的GDB命令：

# 启动GDB并附加到进程
gdb -p <pid>

# 设置断点
break function_name
break file.c:line_number

# 查看变量
print variable_name
print *pointer

# 单步执行
next    # 跳过函数
step    # 进入函数

# 查看调用栈
backtrace
frame <number>

内核调试配置：

要调试内核模块，需要开启以下内核选项：

  • CONFIG_DEBUG_INFO=y
  • CONFIG_KGDB=y
  • CONFIG_KGDB_SERIAL_CONSOLE=y

2.2.2 kdump：内核崩溃转储

kdump是Linux内核的崩溃转储机制。当内核发生panic时，它会保存一份内存快照，供你事后分析。

为什么会需要这个？因为很多驱动bug是偶发的，你盯着它看的时候它不崩，你一转身它就崩了。kdump能帮你抓住「犯罪现场」。

配置kdump的步骤：

# 1. 安装kdump工具
apt-get install kdump-tools

# 2. 配置内核启动参数
# 在/etc/default/grub中添加：
GRUB_CMDLINE_LINUX="crashkernel=256M"

# 3. 更新grub
update-grub

# 4. 重启系统
reboot

# 5. 测试kdump
echo c > /proc/sysrq-trigger

注意：

crashkernel的大小要根据你的系统内存来定。一般建议256M-512M。太小了可能抓不全，太大了浪费内存。我曾经在一个嵌入式设备上设了128M，结果崩溃时只抓到一半数据，白忙活一场。

2.2.3 ftrace：函数跟踪器

ftrace是Linux内核内置的跟踪工具。它可以记录内核函数的调用情况、执行时间、中断上下文等。

我个人觉得，ftrace是调试驱动性能问题的最佳工具。没有之一。

基本用法：

# 挂载tracefs
mount -t tracefs nodev /sys/kernel/tracing

# 设置跟踪器
echo function > /sys/kernel/tracing/current_tracer

# 设置要跟踪的函数
echo my_driver_function > /sys/kernel/tracing/set_ftrace_filter

# 开始跟踪
echo 1 > /sys/kernel/tracing/tracing_on

# 执行你的驱动操作
# ...

# 停止跟踪
echo 0 > /sys/kernel/tracing/tracing_on

# 查看结果
cat /sys/kernel/tracing/trace

进阶技巧：

使用function_graph跟踪器，可以看到函数的调用关系图。这对于理解驱动代码的执行路径非常有帮助。

echo function_graph > /sys/kernel/tracing/current_tracer

2.3 环境配置实战

理论说完了，我们来动手配置一个完整的调试环境。

2.3.1 硬件连接

以ARM Cortex-A系列处理器为例：

  1. 将JTAG调试器的20针接口连接到目标板的JTAG插座
  2. 连接USB线到主机
  3. 连接逻辑分析仪的探头到目标信号引脚
  4. 确保所有设备共地

连接检查清单：

  • JTAG的TCK、TMS、TDI、TDO信号是否连通？
  • 逻辑分析仪的采样率是否足够？
  • 目标板供电是否正常？
  • 调试器驱动是否安装？

2.3.2 软件环境配置

我建议使用Ubuntu 20.04或22.04作为开发主机。以下是配置步骤：

# 安装GDB
apt-get install gdb gdb-multiarch

# 安装交叉编译工具链
apt-get install gcc-arm-linux-gnueabihf

# 安装kdump
apt-get install kdump-tools

# 安装ftrace相关工具
apt-get install trace-cmd kernelshark

# 配置内核调试符号
apt-get install linux-image-$(uname -r)-dbg

2.3.3 验证环境

配置完成后，我们来验证一下：

# 验证GDB
gdb --version

# 验证JTAG连接
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg

# 验证kdump
kdump-config show

# 验证ftrace
cat /sys/kernel/tracing/available_tracers

我的习惯：

每次开始新项目前，我都会花30分钟重新验证调试环境。别嫌麻烦，这30分钟能帮你省下后面几天的排查时间。

好了，调试环境搭建就讲到这里。下一章，我们会深入讲解如何用这些工具定位驱动稳定性问题。记住，工具只是手段，关键是要理解它们背后的原理。

← 上一章 📖 返回目录 下一章 →