ADC调试踩坑：一个printf引发的“血案“

STM32 ADC调试踩坑记：一个printf引发的"血案"

前言

最近在调试STM32F429的ADC注入通道功能时，遇到了一个"诡异"的问题：注入通道转换完成后，规则通道停止更新。

经过一番寄存器级调试，我找到了"解决方案"，但最后发现——真正的凶手竟然是调试用的printf！

这个调试过程很有意思，记录下来分享给大家。

源码

仓库地址：https://github.com/SXSBJS-XYT/STM32/tree/ADC/ADC

环境信息

• MCU: STM32F429IGT6
• 开发工具: CubeMX + Keil MDK
• HAL库版本: STM32Cube_FW_F4 V1.28.3

问题描述

功能需求

• 规则通道(PA0)：连续转换模式，后台持续采集
• 注入通道(PA2)：软件触发，高优先级打断规则通道

预期行为

按照STM32参考手册(RM0090)的描述：

11.3.9 注入通道管理 - 触发注入

1. 通过外部触发或将ADC_CR2寄存器中的SWSTART位置1来启动规则通道组转换。
2. 如果在规则通道组转换期间出现外部注入触发或者JSWSTART位置1，则当前的转换会复位，并且注入通道序列会切换为单次扫描模式。
3. 然后，规则通道组的规则转换会从上次中断的规则转换处恢复。

手册明确说注入完成后规则通道会自动恢复。

规则通道: [转换][转换][暂停][转换][转换]... ↑ ↑ 注入通道: 触发 完成 打断 自动恢复

实际现象

规则通道: [转换][转换][停止] ↑ 注入通道: 触发 打断后再也不恢复！

规则通道只在初始化后更新一次，触发注入后就再也不更新了。

第一轮调试：寄存器分析

定位问题边界

通过对比测试：

问题出在两者的交互上。

寄存器调试

在注入完成回调里打印寄存器：

voidHAL_ADCEx_InjectedConvCpltCallback(ADC_HandleTypeDef*hadc){s_injected_value=HAL_ADCEx_InjectedGetValue(hadc,ADC_INJECTED_RANK_1);printf("CR2=0x%08lX, SR=0x%08lX\r\n",hadc->Instance->CR2,hadc->Instance->SR);}

输出结果：

CR2=0x00000403, SR=0x00000008

寄存器解析

CR2 = 0x00000403：

SR = 0x00000008：

ADC没关，连续模式还在，但规则通道的启动位被清除了！

初步结论与修复

当时的分析：HAL库的问题，手册说会自动恢复，但实际没恢复。

修复方案——在回调里手动重启规则通道：

voidHAL_ADCEx_InjectedConvCpltCallback(ADC_HandleTypeDef*hadc){s_injected_value=HAL_ADCEx_InjectedGetValue(hadc,ADC_INJECTED_RANK_1);/* "修复"：手动重启规则通道 */hadc->Instance->CR2|=ADC_CR2_SWSTART;printf("CR2=0x%08lX, SR=0x%08lX\r\n",hadc->Instance->CR2,hadc->Instance->SR);}

加上这行后，规则通道确实恢复工作了。问题"解决"，准备写博客吐槽HAL库…

剧情反转：真正的凶手

在整理代码时，我注释掉了调试用的printf，顺便也注释掉了SWSTART那行"修复"代码：

voidHAL_ADCEx_InjectedConvCpltCallback(ADC_HandleTypeDef*hadc){s_injected_value=HAL_ADCEx_InjectedGetValue(hadc,ADC_INJECTED_RANK_1);s_injected_ready=true;// hadc->Instance->CR2 |= ADC_CR2_SWSTART; // 注释掉// printf("CR2=0x%08lX, SR=0x%08lX\r\n",// hadc->Instance->CR2,// hadc->Instance->SR);}

神奇的事情发生了——规则通道正常工作了！

验证测试

• 有printf，无SWSTART ，规则通道停止

• 有printf，有SWSTART ，规则通道工作
  
• 无printf，无SWSTART ，规则通道工作
  
• 无printf，有SWSTART ，规则通道工作
  

真相大白：printf才是罪魁祸首！

根因分析

ADC转换时间: 约4.36μs (84采样周期 + 12周期 @ 22MHz) printf执行时间: 约500μs~2ms (取决于波特率和字符串长度)

时间线对比：

有printf时: ↓ 注入完成中断 中断回调: [读JDR][──────printf执行中(500μs+)──────][返回] 规则通道: 暂停...等待...等待...超时/异常？...停止 无printf时: ↓ 注入完成中断 中断回调: [读JDR][置标志][返回] ← 几μs 规则通道: 暂停 → 立即恢复 ✓

printf通过串口发送数据，在115200波特率下发送40个字符大约需要3.5ms，而ADC硬件期望中断快速返回以恢复规则通道转换。

长时间占用中断，干扰了ADC硬件的自动恢复机制！

为什么寄存器显示SWSTART=0？

这其实是正常的！SWSTART是触发位，置1后硬件自动清零：

SWSTART位由软件置1来启动转换，转换开始后由硬件清零。

在printf执行期间读取CR2，当然看到的是0。这并不意味着规则通道"没启动"，而是"启动信号已经过去了"。

当时的分析思路错了——看到SWSTART=0就以为需要重新置位，实际上是printf延迟导致的错觉。

为什么加上SWSTART能"修复"？

虽然printf导致了问题，但在回调里加上CR2 |= ADC_CR2_SWSTART确实能让规则通道恢复：

voidHAL_ADCEx_InjectedConvCpltCallback(ADC_HandleTypeDef*hadc){s_injected_value=HAL_ADCEx_InjectedGetValue(hadc,ADC_INJECTED_RANK_1);printf("...");// 干扰硬件自动恢复hadc->Instance->CR2|=ADC_CR2_SWSTART;// 手动补救}

这是"治标不治本"的方案——用软件手段弥补了printf带来的破坏。

最终正确的写法

voidHAL_ADCEx_InjectedConvCpltCallback(ADC_HandleTypeDef*hadc){if(hadc==s_hadc){s_injected_value=HAL_ADCEx_InjectedGetValue(hadc,ADC_INJECTED_RANK_1);s_injected_ready=true;s_trigger_count++;/* 不要在这里printf！ *//* 不需要手动重启规则通道，硬件会自动恢复 */}}

如果确实需要调试输出，用标志位在主循环里打印：

/* 中断回调 - 快进快出 */voidHAL_ADCEx_InjectedConvCpltCallback(ADC_HandleTypeDef*hadc){s_injected_value=HAL_ADCEx_InjectedGetValue(hadc,ADC_INJECTED_RANK_1);s_debug_flag=true;// 设置标志}/* 主循环 - 在这里打印 */while(1){if(s_debug_flag){s_debug_flag=false;printf("Injected: %d\r\n",s_injected_value);}}

总结

问题根因

不是HAL库的bug，不是芯片的问题，是调试代码(printf)在中断里执行太久，干扰了ADC硬件的自动恢复机制。

核心教训

1. 中断回调要快进快出：不要在中断里做printf、HAL_Delay等耗时操作
2. 调试代码也会引入bug：海森堡效应——观测行为本身影响了被观测对象
3. 不要急于下结论：找到"解决方案"后，要验证根因是否正确
4. 相信手册，但要正确理解：手册说的"自动恢复"是对的，前提是中断正常返回

中断里应该做什么

这次调试经历提醒我：有时候bug不在你怀疑的地方，而在你最信任的地方——比如那行看起来人畜无害的printf。

如果这篇文章对你有帮助，欢迎点赞收藏。有问题可以在评论区讨论。