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 注入通道管理 - 触发注入
- 通过外部触发或将ADC_CR2寄存器中的SWSTART位置1来启动规则通道组转换。
- 如果在规则通道组转换期间出现外部注入触发或者JSWSTART位置1，则当前的转换会复位，并且注入通道序列会切换为单次扫描模式。
- 然后，规则通道组的规则转换会从上次中断的规则转换处恢复。
手册明确说注入完成后规则通道会自动恢复。
规则通道: [转换][转换][暂停][转换][转换]... ↑ ↑ 注入通道: 触发 完成 打断 自动恢复实际现象
规则通道: [转换][转换][停止] ↑ 注入通道: 触发 打断后再也不恢复！规则通道只在初始化后更新一次，触发注入后就再也不更新了。
第一轮调试：寄存器分析
定位问题边界
通过对比测试：
| 测试场景 | 结果 |
|---|---|
| 只启动规则通道（不触发注入） | ✓ 正常，持续更新 |
| 只触发注入通道 | ✓ 正常，回调触发 |
| 规则+注入同时使用 | ✗ 注入后规则停止 |
问题出在两者的交互上。
寄存器调试
在注入完成回调里打印寄存器：
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：
| Bit | 名称 | 值 | 含义 |
|---|---|---|---|
| 0 | ADON | 1 | ADC开启 ✓ |
| 1 | CONT | 1 | 连续转换模式 ✓ |
| 30 | SWSTART | 0 | 规则通道启动位 = 0 ← 问题！ |
SR = 0x00000008：
| Bit | 名称 | 值 | 含义 |
|---|---|---|---|
| 3 | JSTRT | 1 | 注入通道已启动 |
| 4 | STRT | 0 | 规则通道未启动 ← 问题！ |
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，无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硬件的自动恢复机制。
核心教训
- 中断回调要快进快出：不要在中断里做printf、HAL_Delay等耗时操作
- 调试代码也会引入bug：海森堡效应——观测行为本身影响了被观测对象
- 不要急于下结论：找到"解决方案"后，要验证根因是否正确
- 相信手册，但要正确理解：手册说的"自动恢复"是对的，前提是中断正常返回
中断里应该做什么
| 允许 | 禁止 |
|---|---|
| 读写寄存器 | printf/sprintf |
| 设置标志位 | HAL_Delay |
| 读写全局变量 | 复杂计算 |
| 短小的赋值操作 | 调用阻塞函数 |
这次调试经历提醒我：有时候bug不在你怀疑的地方，而在你最信任的地方——比如那行看起来人畜无害的printf。
如果这篇文章对你有帮助，欢迎点赞收藏。有问题可以在评论区讨论。
