📚 课程目录第4章内存与寄存器查看

4. 内存与寄存器查看：内存映射、寄存器读写、变量监视、内存修改

调试驱动，说白了就是跟内存和寄存器打交道。你写的代码最终都变成对某个地址的读写。我见过太多工程师，代码逻辑分析得头头是道，结果一查寄存器，值根本不对。嗯，今天我们就来把这套基本功练扎实。

4.1 内存映射：你得知道你的设备在哪

每个外设都有一块属于自己的地址空间。比如一个UART控制器，它的寄存器可能从 0x10001000 开始。这块地址空间，就是它的内存映射。

我个人习惯，拿到一个新板子，第一件事就是看芯片手册的“Memory Map”章节。那里会告诉你，哪个地址段是SRAM，哪个是外设寄存器，哪个是DDR。

核心概念： 内存映射就是把物理地址分配给不同的硬件模块。驱动通过访问这些地址来控制硬件。

举个例子，一个典型的嵌入式SoC内存映射可能长这样：

起始地址	结束地址	大小	用途
0x0000_0000	0x0000_FFFF	64KB	内部SRAM
0x4000_0000	0x4000_FFFF	64KB	GPIO寄存器
0x4001_0000	0x4001_0FFF	4KB	UART0寄存器
0x8000_0000	0x8FFF_FFFF	256MB	DDR内存

在JTAG调试器里，你直接输入这些物理地址，就能看到对应的数据。比如在OpenOCD里：

# 查看UART0的状态寄存器（假设偏移0x00）
mdw 0x40010000 1
# 返回：0x40010000: 000000C1

这个 0xC1 就是寄存器的当前值。你得对照手册，看每一位代表什么。

4.2 寄存器读写：JTAG就是你的示波器

寄存器是硬件的“窗口”。读它，你能知道硬件状态；写它，你能控制硬件行为。

JTAG调试器提供了最直接的寄存器读写命令。我个人最常用的就是 mdw（读32位）和 mww（写32位）。

小技巧： 读寄存器时，我习惯先读一次，再读一次。如果两次值不一样，说明寄存器在变化，可能是硬件在自动更新。如果两次一样，那这个值就是当前稳态。

看一个实际例子。假设你要配置GPIO输出高电平：

# 1. 先读当前GPIO方向寄存器
mdw 0x40000004 1
# 返回：0x40000004: 00000000  （所有引脚都是输入）

# 2. 设置GPIO0为输出（写1到位0）
mww 0x40000004 0x00000001

# 3. 再读确认
mdw 0x40000004 1
# 返回：0x40000004: 00000001  （设置成功）

# 4. 设置GPIO0输出高电平
mww 0x40000008 0x00000001

每一步都能看到效果。这就是JTAG调试的魅力——你不再靠猜，而是亲眼看到硬件的变化。

注意： 写寄存器要小心。有些寄存器是“写1清零”的，你写个0xFFFFFFFF进去，可能把不该清的状态全清了。我曾经在调试DMA时，不小心写错了中断状态寄存器，导致中断丢失，查了整整一天。

4.3 变量监视：让C代码“透明”

调试驱动时，你不仅要看寄存器，还要看C代码里的变量。比如一个缓冲区指针、一个计数器、一个状态标志。

JTAG调试器支持直接查看变量地址。你只需要知道变量的符号名，或者它的内存地址。

在GDB里，你可以这样：

# 查看全局变量 g_tx_buffer
print g_tx_buffer
# 返回：$1 = 0x20000100 "Hello"

# 查看局部变量 count（需要先停在函数里）
print count
# 返回：$2 = 42

# 查看结构体
print *p_uart_dev
# 返回：$3 = {base_addr = 0x40010000, irq_num = 33, baud = 115200}

我个人习惯，在调试中断处理函数时，会在函数入口设一个断点。然后每次停下来，都看一眼关键变量。比如：

# 在UART中断处理函数里
print rx_count
print rx_buffer[0..15]  # 看前16个字节

这样你就能知道，中断来了多少次，数据有没有被正确接收。

核心技巧： 变量监视的关键是“对比”。你预期变量应该是某个值，实际看是不是。如果不是，那问题就出在从“预期”到“实际”的这段代码里。

4.4 内存修改：给硬件“打补丁”

有时候，你需要在运行时修改内存或寄存器的值，来验证你的假设。这就是内存修改的用途。

比如，你怀疑一个缓冲区被写坏了。你可以先读出来看看：

# 读缓冲区前16个字节
mdw 0x20000100 4
# 返回：
# 0x20000100: 48656C6C 6F20576F 726C6421 00000000
# 对应ASCII: "Hello World!"

然后你手动修改它，模拟一个错误场景：

# 把第一个字改成0xDEADBEEF
mww 0x20000100 0xDEADBEEF

# 再读确认
mdw 0x20000100 1
# 返回：0x20000100: DEADBEEF

这样，你就能测试你的代码是否能正确处理坏数据。

实用场景： 我经常用内存修改来“欺骗”硬件。比如某个外设的状态寄存器一直显示“忙”，我就手动把它改成“空闲”，看看我的驱动能不能继续往下走。这比改代码重新编译快多了。

4.5 知识结构图：内存与寄存器调试全景

下面这张图，把刚才讲的内容串起来了。你可以看到，从物理地址出发，我们怎么一步步深入到变量和内存修改。

4.6 避坑指南：我踩过的那些坑

最后，分享几个我实际项目中遇到的教训：

寄存器地址对齐： 有些外设要求32位访问必须4字节对齐。你写个 mww 0x40010001 0x12345678，可能直接触发异常。我吃过这个亏，后来每次写地址前都检查一下低两位是不是0。
缓存一致性问题： 如果你在调试时修改了DDR里的数据，但CPU的Cache里还有旧副本，那CPU读到的还是旧值。这时候需要先Clean+Invalidate Cache。我记得有一次调试网络驱动，改了缓冲区数据但发包内容没变，折腾了半天才发现是Cache没刷新。
只读寄存器： 有些寄存器是只读的，你写它没反应。但更坑的是，有些寄存器“写1清零”，你写个0进去，它纹丝不动。我建议，在写任何寄存器之前，先读一下手册，确认它的读写属性。
变量优化： 编译器可能把变量优化掉，或者放在寄存器里。你在GDB里 print 一个局部变量，可能看到 <optimized out>。这时候，要么加 volatile，要么把变量改成全局的。我个人习惯，调试阶段的关键变量都声明成 volatile，省得编译器跟我玩捉迷藏。

好了，内存与寄存器查看这块，核心就是“读、写、改、看”。你把这四个动作练熟了，大部分驱动问题都能在JTAG面前现出原形。