📚 课程目录第3章多核同步调试

3、多核同步调试：同步断点设置、多核单步执行、跨核变量监控

多核调试，说白了就是同时控制多个大脑。每个 Cortex-M 核心都有自己的程序计数器、堆栈指针和调试接口。你让它们各自跑各自的，那叫独立调试。真正的多核同步调试，是要让所有核心在同一个时间点停下来，然后你一个一个看它们的状态。

我记得第一次做双核同步调试时，断点设好了，一运行，Core0 停了，Core1 还在跑。我当时就懵了——这怎么查竞态条件？后来才明白，多核调试的断点，不是你想的那样简单。

3.1 同步断点：让所有核心同时停下

同步断点的核心机制，是硬件断点触发后，通过调试接口向其他核心发送 halt 请求。ARM Cortex-M 的调试架构里，每个核心都有独立的 DHCSR（Debug Halting Control and Status Register）。你往 Core0 的 DHCSR 写个 halt 位，Core0 就停了。但 Core1 不会自动停。

那怎么办？有两种主流做法：

方式	原理	延迟	适用场景
硬件交叉触发	Core0 断点触发 → 硬件信号直接 halt Core1	1-2 个时钟周期	时序敏感、竞态分析
软件同步断点	Core0 断点触发 → 调试器通过 SWD/JTAG 发 halt 给 Core1	几十微秒到毫秒级	通用调试、非实时场景

关键点：硬件交叉触发需要芯片设计时就支持。Cortex-M7 + M4 的异构多核芯片，很多都带这个功能。同构多核（比如双 M4）反而要看具体厂商实现。

我个人习惯，在 Keil 或 IAR 里配置同步断点时，先确认调试器是否支持「多核同步 halt」。以 J-Link 为例，你需要在初始化脚本里加上：

// J-Link 脚本示例：使能多核同步断点
// 假设 Core0 在 DAP 端口 0，Core1 在 DAP 端口 1
CORESIGHT_AddAPBAP(0);
CORESIGHT_AddAPBAP(1);
CORESIGHT_Configure("Core0", "AP=0");
CORESIGHT_Configure("Core1", "AP=1");
// 使能交叉触发
CORESIGHT_WriteAP(0, 0x004, 0x00000001);  // 使能 Core0 触发输出
CORESIGHT_WriteAP(1, 0x004, 0x00000002);  // 使能 Core1 触发接收

注意：软件同步断点有个坑——Core0 停了，Core1 还在跑。等你调试器发 halt 过去，Core1 已经跑过好几条指令了。这时候你看到的「同步」状态，其实是假的。我曾经因为这个，查了一个星期的死锁问题，最后发现是断点不同步导致的误判。

3.2 多核单步执行：一步一步，一起走

单步执行在多核环境下，比单核复杂得多。单核单步，就是执行一条指令，然后停下来。多核单步呢？你要让所有核心都执行一条指令，然后全部停下来。

这里有个核心问题：指令边界对齐。Core0 执行一条加法指令，Core1 可能正在执行一条多周期的乘法指令。你让 Core0 停，Core1 还没执行完，那 Core1 的状态就是不完整的。

我建议的做法是：

先同步 halt：确保所有核心都停在已知位置。
设置单步模式：每个核心的 DHCSR 里都有单步使能位（C_MASKINTS 和 C_STEP）。
同时释放：通过调试接口同时清除所有核心的 halt 状态。
等待所有核心 halt：轮询每个核心的 DHCSR，直到全部进入 halt。

代码实现大概是这样的：

// 伪代码：多核同步单步
void multi_core_step() {
    // 1. 使能所有核心的单步模式
    for (int i = 0; i < NUM_CORES; i++) {
        write_dhcsr(i, DHCSR_C_STEP | DHCSR_C_MASKINTS);
    }
    // 2. 同时释放所有核心
    for (int i = 0; i < NUM_CORES; i++) {
        write_dhcsr(i, DHCSR_C_STEP | DHCSR_C_MASKINTS | DHCSR_C_HALT);
        // 注意：先清除 halt，再写 step
    }
    // 3. 等待所有核心 halt
    uint32_t status;
    do {
        status = 0;
        for (int i = 0; i < NUM_CORES; i++) {
            if (read_dhcsr(i) & DHCSR_S_HALT) {
                status |= (1 << i);
            }
        }
    } while (status != ((1 << NUM_CORES) - 1));
}

经验之谈：实际调试时，同步单步非常慢。因为每次单步都要轮询所有核心。我一般只在分析特定竞态条件时才用。平时调试，我更倾向于用硬件断点 + 条件触发。

3.3 跨核变量监控：看一个变量，管两个核

跨核变量监控，是调试共享数据竞争的关键。你想想看，一个全局变量，Core0 在写，Core1 在读。你只监控 Core0 的视角，看不到 Core1 什么时候读的，那怎么查问题？

ARM Cortex-M 的调试架构里，每个核心都有 DWT（Data Watchpoint and Trace）单元。DWT 可以监控内存地址的读写访问。但问题是，DWT 是每个核心独立的。Core0 的 DWT 只能监控 Core0 对内存的访问，看不到 Core1 的。

那怎么办？我常用的方法有三种：

方法	实现方式	优点	缺点
双 DWT 同步	Core0 和 Core1 各自设置 DWT，监控同一个地址	硬件级，零开销	DWT 数量有限（通常 4 个）
共享内存日志	在共享 RAM 里写环形缓冲区，记录每次访问	灵活，可记录上下文	有侵入性，影响时序
ETM 跟踪	用 ETM 跟踪所有核心的数据访问	无侵入，全量记录	需要硬件支持，数据量大

我个人最常用的是双 DWT 同步。设置方法很简单：

// Core0 设置 DWT，监控地址 0x20001000 的写操作
DWT0_COMP = 0x20001000;   // 比较地址
DWT0_MASK = 0;            // 精确匹配
DWT0_FUNCTION = 0x5;      // 写操作触发

// Core1 设置 DWT，监控同一个地址的读操作
DWT0_COMP = 0x20001000;
DWT0_MASK = 0;
DWT0_FUNCTION = 0x6;      // 读操作触发

然后，两个核心的 DWT 触发后，都会产生调试事件。你可以在调试器里看到哪个核心触发了，以及触发时的指令地址。

避坑指南：我曾经遇到过一个情况——Core0 和 Core1 的 DWT 都设好了，但只有 Core0 能触发。查了半天，发现是 Core1 的 DWT 时钟没使能。很多芯片的 DWT 模块默认是关闭的，需要你在系统初始化时手动使能。别忘了检查 DEMCR 寄存器的 TRCENA 位。

3.4 实战：用同步调试查一个经典的竞态条件

光说不练假把式。我们来看一个实际例子。假设有一个共享计数器：

// 共享变量
volatile uint32_t shared_counter = 0;

// Core0 的任务
void core0_task() {
    for (int i = 0; i < 1000; i++) {
        shared_counter++;  // 读-改-写
    }
}

// Core1 的任务
void core1_task() {
    for (int i = 0; i < 1000; i++) {
        shared_counter++;  // 读-改-写
    }
}

理论上，最终结果应该是 2000。但实际跑起来，经常是 1998、1999，甚至更少。这就是经典的读-改-写竞态。

用同步调试怎么查？

设置同步断点：在 shared_counter++ 的汇编指令处，给两个核心都设断点。
运行到断点：两个核心同时停下来。
查看寄存器：看 Core0 的 R0（假设存了 shared_counter 的值）和 Core1 的 R0。
单步执行：同步单步，看谁先写回。

你会发现，当 Core0 读到了 100，Core1 也读到了 100。然后 Core0 写回 101，Core1 也写回 101。结果就是 101，而不是 102。这就是竞态。

核心思路：同步调试不是为了修 bug，而是为了「看到」bug 发生的那一刻。你看到了，就知道怎么加锁、怎么用原子操作了。

嗯，到这里，多核同步调试的核心方法就讲完了。同步断点让你能同时停住所有核心，多核单步让你能一步一步地观察指令执行顺序，跨核变量监控让你能看到同一个变量在不同核心上的访问情况。这三招用好了，大部分多核竞态问题都能在调试器里现形。