4、单步执行与追踪：Step Over、Step Into、Step Return的实战应用

调试工业通信芯片，说白了就是在跟看不见的信号赛跑。你写好了驱动，配置好了寄存器，结果通信就是不通。这时候，单步执行就是你手里最趁手的兵器。

我个人习惯把单步调试分成两类：源码级单步和指令级单步。很多新手上来就点Step Over，结果跳过了关键的中断处理，查了半天找不到问题。嗯，这里面的门道，我慢慢跟你聊。

4.1 三个核心动作：Step Over、Step Into、Step Return

这三个按钮，几乎每个调试器上都有。但你真的用对了吗？

4.2 实战案例：调试SPI从机接收

我记得有一次调试一个SPI从机芯片，主机发过来的数据总是少一个字节。我当时的代码大概是这样：

void SPI_IRQHandler(void)
{
    uint8_t rx_data;
    
    if(SPI->SR & SPI_SR_RXNE)  // 检查接收缓冲区非空
    {
        rx_data = SPI->DR;      // 读取数据
        buffer[head++] = rx_data;
        if(head >= BUFFER_SIZE)
            head = 0;
    }
    
    // 这里还有别的处理...
    process_data();
}

我一开始用Step Over跑，发现每次进中断后，buffer里的数据确实少了一个。后来我改用Step Into钻进process_data()函数，才发现里面有个延时操作，把下一个字节给错过了。

4.3 指令级单步 vs 源码级单步

这两个模式的区别，说白了就是：你看的是C代码，还是汇编代码。

• 源码级单步：调试器按C语言的行来执行。一行C代码可能对应多条汇编指令。适合验证逻辑。
• 指令级单步：调试器按CPU指令来执行。每点一下，CPU就执行一条汇编指令。适合排查底层问题。

你想想看，什么时候需要用指令级单步？

我遇到过一种情况：芯片在某个中断里跑飞了，但源码级单步怎么都复现不了。后来我切换到指令级单步，发现是编译器优化导致指令顺序变了。C代码里先写A再写B，但汇编里先执行了B。这种问题，源码级单步根本看不出来。

4.4 什么时候用哪种模式？

我总结了一个简单的判断方法：

1. 查逻辑错误（比如if条件写反了）→ 用源码级单步，Step Over为主
2. 查时序问题（比如中断响应慢了）→ 用指令级单步，数一下执行了多少条指令
3. 查外设配置（比如SPI波特率对不对）→ 用源码级单步，Step Into钻进配置函数
4. 查堆栈溢出或指针乱飞→ 用指令级单步，盯着PC指针和SP指针看

4.5 实战中的组合拳

最后分享一个我常用的调试流程：

假设我在调试一个Modbus RTU从机，通信时好时坏。

• 第一步：在接收中断入口处打个断点，用Step Over跑一遍。确认每次主机发数据都能进中断。
• 第二步：如果发现中断进得不对，用Step Into钻进中断配置函数，检查NVIC和GPIO的配置。
• 第三步：如果中断正常但数据不对，切换到指令级单步，看看从读取DR寄存器到存入buffer，中间有没有被其他中断打断。
• 第四步：确认问题后，用Step Return快速跳出当前函数，继续跑下一个流程。

说白了，这三个动作不是孤立的。你得根据现场情况灵活切换。我见过有人从头到尾只用Step Over，结果查了三天没找到问题。也见过有人每步都Step Into，结果把自己绕晕在底层库里。

嗯，单步执行这东西，用好了是神器，用不好是累赘。多练练，找到自己的节奏就好。