先交代一下背景。最近在调一块 STM32C092 的板子需求非常简单USART1 接一个串口屏115200 波特率printf 重定向输出调试信息。按说这是嵌入式里最基础的操作但项目组偏偏在这上面卡了一个下午——现象是串口助手能收到数据但全是乱码偶尔还会蹦出几个看起来挺正常的 ASCII 字符。老手可能已经猜到十有八九是时钟clocking的问题可真正动手查的时候才会发现STM32C0 这一代小芯片的时钟树跟 F1、G0 都有微妙差别USART1 的时钟一旦没理顺后面所有外设都跟着遭殃。这篇文章就把整个排查思路、寄存器级验证过程、以及最终修复方案完整记录一下给正在用 STM32C092 或者其他 C0 系列的朋友做个参考。1. 先搞清楚USART1的时钟到底从哪来1.1 STM32C092的时钟树比你想的简单STM32C092 内核是 Cortex-M0最高 48MHz定位就是低成本、低引脚数、够用就行的场景。它的时钟树没有 F4 那种复杂的多级 PLL 网络也没有 F1 那种需要来回切换 AHB、APB1、APB2 的繁琐总线结构。整个链路其实很清晰系统时钟 SYSCLK 经过 AHB 预分频得到 HCLKHCLK 再经过 APB 预分频得到 PCLK而 USART1 用的就是 PCLK。这句话听起来很普通但它直接决定了你排查的方向。很多人习惯性去翻USART 外设时钟使能寄存器却忽略了先确认 PCLK 到底是多少。PCLK 是 48MHz 还是 24MHz是复位默认值还是你自己配置的分频结果直接决定了波特率寄存器 BRR 里应该填哪个数。我在 C092 上遇到的所有 USART1 时钟问题最后几乎都归结到同一个根因代码里假设的 PCLK 和芯片实际输出的 PCLK 不一致。所以第一步不是打开调试器盯着 USART1 寄存器看而是先把时钟树这张图刻在脑子里SYSCLK → HCLK → PCLK → USART1。中间任意一级的分频比发生变化USART1 的波特率就会跟着变。C0 系列还阉割了不少东西外部晶振 HSE 也不是所有封装都有这意味着你连换一个外部晶振这种常规后路都可能没有内部 RC 就是唯一的稳定来源。这种前提下搞清楚内部 RC 的频率和使能状态比什么都重要。1.2 默认时钟源别拿老经验套新芯片我踩的第一个坑就是拿着 STM32F0 的老经验去套 C092。F103 复位后默认跑 8MHz 内部 HSIG0 系列复位后是 16MHz 的 HSI16而 C0 这一代上电后系统时钟默认来自内部 48MHz 的 RCHSI48。如果你代码里的 SystemClock_Config 因为某种原因没执行、或者被你自己注释掉了那么芯片实际上是顶着 48MHz 在跑的而不是你以为的 16MHz 或者别的频率。这个差异在串口上表现得极其明显。老项目里 USART1 的波特率寄存器是按 16MHz 算的BRR 填的是 139对应 16MHz / 115200。结果在 C092 上芯片实际跑 48MHz同样一个 BRR 值产生的实际波特率就变成了 48MHz / 139约 345k跟 115200 差了整整三倍。接收端当然是一头雾水出来的全是乱码。这里最该记住的不是 C092 默认 48MHz这个结论而是永远不要靠记忆去推默认时钟源。芯片型号、批次、封装不同甚至参考手册版本不同复位默认值都可能不一样。正确做法是上电后直接读 RCC_CFGR 的 SWS 位段看看系统时钟到底切到了哪个源再结合 RCC_CR 里对应振荡器的 RDY 位确认它真的稳定了。读寄存器只花你五秒钟却能省下一下午的抓头时间。1.3 时钟使能位USART1不在APB2上从 F103 迁移过来的朋友请注意这是第二个高频坑。F103 上 USART1 挂在 APB2 总线上使能代码一般写成RCC-APB2ENR | RCC_APB2ENR_USART1EN。到了 STM32C0 系列总线和寄存器划分不一样了USART1 的时钟使能位在RCC_APBENR1里面不是 APB2ENR。如果你照抄老代码这一行根本不起作用USART1 外设压根没得到时钟。在 Cortex-M0 上有个讨厌的地方外设没时钟时你去读它的寄存器有些会读到全 0但不会像 M3/M4 那样触发总线错误或者 HardFault所以问题变得很隐蔽。你写了一堆 USART1-CR1、USART1-BRR读回来全是 0但程序照常运行没有任何异常提示。裸机写法正确的是这样// STM32C0 系列USART1 的使能位在 APBENR1 RCC-APBENR1 | RCC_APBENR1_USART1EN;如果你用的是 STM32Cube HAL就简单了__HAL_RCC_USART1_CLK_ENABLE();不管哪种写法我建议你养成一个习惯初始化完外设之后反读一下状态寄存器确认寄存器能读到非零值。比如把 BRR 写进去之后立刻读回来如果还是 0先别怀疑波特率公式回去检查时钟使能位和内核时钟选择位。另外STM32C0 的 RCC 里还有一个 CCIPR 寄存器里面放着 USART1SW 位段用来选择 USART1 的内核时钟源。默认是 0也就是 PCLK。如果有人手贱把它改成了内部 RC 或者 LSE那么你所有基于 PCLK 的 BRR 计算全部作废。2. 乱码的本质波特率公式与BRR寄存器2.1 BRR的计算一步一步来USART 波特率的原理不复杂但每次都要重算确实烦。在过采样倍数 OVER8 0即 16 倍过采样时USARTDIV fck / (16 × baud)。BRR 寄存器里存的是这个 USARTDIV 的定点表示高 12 位是整数部分低 4 位是小数部分小数位每个单位代表 1/16。手动算的话以 48MHz 和 115200 为例48000000 / (16 × 115200) 26.0417整数部分 26小数部分 0.0417 × 16 0.667四舍五入取 1所以 BRR 26 4 | 1 0x1A1 417这里有个很实用的简化计算技巧当 OVER8 0 时BRR 的数值本质上就是 fck / baud 四舍五入的结果。因为 BRR 整数部分 4 | 小数部分 × 16整体上就是在算 fck / (16 × baud) 放大 16 倍后取整约等于 fck / baud。所以你可以直接写uint32_t pclk 48000000u; // 以实际读取的 SWS 为准不要拍脑袋 uint32_t baud 115200u; uint32_t brr (pclk baud / 2u) / baud; // 四舍五入 USART1-BRR brr;这个写法在做裸机移植的时候特别好用一行代码搞定也不会在小数部分四舍五入上栽跟头。常见频率的 BRR 值可以列个表PCLK960011520048MHz0x1388 (5000)0x01A1 (417)16MHz0x0683 (1667)0x008B (139)8MHz0x0341 (833)0x0045 (69)算完 BRR 之后最好顺手验证一下误差。48MHz 下 BRR 417实际波特率 48000000 / 417 115108误差约 0.08%远在 ±2% 的容差范围内。但如果你用 8MHz 跑 115200误差会明显变大高波特率场景下就需要注意了。2.2 为什么一改系统时钟串口就崩这个问题的典型场景是这样的板子刚上电BootLoader 或者早期初始化代码用默认时钟把 USART1 调好了115200 通得很开心。然后在 main 函数里某段从别的项目抄来的代码把系统时钟从 HSI 切到了 PLL或者把 APB 预分频从 /1 改成了 /2。改完时钟之后USART1 的 BRR 还是原来那个值但 PCLK 已经变了波特率自然就偏了。还有一种更隐蔽的情况你开了 USB 或者其他外设CubeMX 为了满足约束条件自动把 APB 预分频调成了 /2PCLK 从 48MHz 掉到 24MHz。这时候你把代码生成出来如果没仔细看 HAL_RCC_ClockConfig 里给了什么分频系数就会拿着一套看起来正确的配置跑然后莫名其妙死在串口上。我的建议很简单所有外设的初始化必须放在系统时钟最终确定之后。在 C092 这种小芯片上我甚至建议把时钟配置做成一个独立函数在 main 最开头调用确定之后再去做 GPIO、USART、定时器的初始化。如果你中途真的不得不改时钟哪怕只是换一个分频系数也要建立一个改时钟必改 BRR的条件反射。这个坑我踩过不止一次每次都是同一个套路先怀疑代码逻辑查半天最后一看原来是 APB 预分频变了
先交代一下背景。最近在调一块 STM32C092 的板子需求非常简单USART1 接一个串口屏115200 波特率printf 重定向输出调试信息。按说这是嵌入式里最基础的操作但项目组偏偏在这上面卡了一个下午——现象是串口助手能收到数据但全是乱码偶尔还会蹦出几个看起来挺正常的 ASCII 字符。老手可能已经猜到十有八九是时钟clocking的问题可真正动手查的时候才会发现STM32C0 这一代小芯片的时钟树跟 F1、G0 都有微妙差别USART1 的时钟一旦没理顺后面所有外设都跟着遭殃。这篇文章就把整个排查思路、寄存器级验证过程、以及最终修复方案完整记录一下给正在用 STM32C092 或者其他 C0 系列的朋友做个参考。1. 先搞清楚USART1的时钟到底从哪来1.1 STM32C092的时钟树比你想的简单STM32C092 内核是 Cortex-M0最高 48MHz定位就是低成本、低引脚数、够用就行的场景。它的时钟树没有 F4 那种复杂的多级 PLL 网络也没有 F1 那种需要来回切换 AHB、APB1、APB2 的繁琐总线结构。整个链路其实很清晰系统时钟 SYSCLK 经过 AHB 预分频得到 HCLKHCLK 再经过 APB 预分频得到 PCLK而 USART1 用的就是 PCLK。这句话听起来很普通但它直接决定了你排查的方向。很多人习惯性去翻USART 外设时钟使能寄存器却忽略了先确认 PCLK 到底是多少。PCLK 是 48MHz 还是 24MHz是复位默认值还是你自己配置的分频结果直接决定了波特率寄存器 BRR 里应该填哪个数。我在 C092 上遇到的所有 USART1 时钟问题最后几乎都归结到同一个根因代码里假设的 PCLK 和芯片实际输出的 PCLK 不一致。所以第一步不是打开调试器盯着 USART1 寄存器看而是先把时钟树这张图刻在脑子里SYSCLK → HCLK → PCLK → USART1。中间任意一级的分频比发生变化USART1 的波特率就会跟着变。C0 系列还阉割了不少东西外部晶振 HSE 也不是所有封装都有这意味着你连换一个外部晶振这种常规后路都可能没有内部 RC 就是唯一的稳定来源。这种前提下搞清楚内部 RC 的频率和使能状态比什么都重要。1.2 默认时钟源别拿老经验套新芯片我踩的第一个坑就是拿着 STM32F0 的老经验去套 C092。F103 复位后默认跑 8MHz 内部 HSIG0 系列复位后是 16MHz 的 HSI16而 C0 这一代上电后系统时钟默认来自内部 48MHz 的 RCHSI48。如果你代码里的 SystemClock_Config 因为某种原因没执行、或者被你自己注释掉了那么芯片实际上是顶着 48MHz 在跑的而不是你以为的 16MHz 或者别的频率。这个差异在串口上表现得极其明显。老项目里 USART1 的波特率寄存器是按 16MHz 算的BRR 填的是 139对应 16MHz / 115200。结果在 C092 上芯片实际跑 48MHz同样一个 BRR 值产生的实际波特率就变成了 48MHz / 139约 345k跟 115200 差了整整三倍。接收端当然是一头雾水出来的全是乱码。这里最该记住的不是 C092 默认 48MHz这个结论而是永远不要靠记忆去推默认时钟源。芯片型号、批次、封装不同甚至参考手册版本不同复位默认值都可能不一样。正确做法是上电后直接读 RCC_CFGR 的 SWS 位段看看系统时钟到底切到了哪个源再结合 RCC_CR 里对应振荡器的 RDY 位确认它真的稳定了。读寄存器只花你五秒钟却能省下一下午的抓头时间。1.3 时钟使能位USART1不在APB2上从 F103 迁移过来的朋友请注意这是第二个高频坑。F103 上 USART1 挂在 APB2 总线上使能代码一般写成RCC-APB2ENR | RCC_APB2ENR_USART1EN。到了 STM32C0 系列总线和寄存器划分不一样了USART1 的时钟使能位在RCC_APBENR1里面不是 APB2ENR。如果你照抄老代码这一行根本不起作用USART1 外设压根没得到时钟。在 Cortex-M0 上有个讨厌的地方外设没时钟时你去读它的寄存器有些会读到全 0但不会像 M3/M4 那样触发总线错误或者 HardFault所以问题变得很隐蔽。你写了一堆 USART1-CR1、USART1-BRR读回来全是 0但程序照常运行没有任何异常提示。裸机写法正确的是这样// STM32C0 系列USART1 的使能位在 APBENR1 RCC-APBENR1 | RCC_APBENR1_USART1EN;如果你用的是 STM32Cube HAL就简单了__HAL_RCC_USART1_CLK_ENABLE();不管哪种写法我建议你养成一个习惯初始化完外设之后反读一下状态寄存器确认寄存器能读到非零值。比如把 BRR 写进去之后立刻读回来如果还是 0先别怀疑波特率公式回去检查时钟使能位和内核时钟选择位。另外STM32C0 的 RCC 里还有一个 CCIPR 寄存器里面放着 USART1SW 位段用来选择 USART1 的内核时钟源。默认是 0也就是 PCLK。如果有人手贱把它改成了内部 RC 或者 LSE那么你所有基于 PCLK 的 BRR 计算全部作废。2. 乱码的本质波特率公式与BRR寄存器2.1 BRR的计算一步一步来USART 波特率的原理不复杂但每次都要重算确实烦。在过采样倍数 OVER8 0即 16 倍过采样时USARTDIV fck / (16 × baud)。BRR 寄存器里存的是这个 USARTDIV 的定点表示高 12 位是整数部分低 4 位是小数部分小数位每个单位代表 1/16。手动算的话以 48MHz 和 115200 为例48000000 / (16 × 115200) 26.0417整数部分 26小数部分 0.0417 × 16 0.667四舍五入取 1所以 BRR 26 4 | 1 0x1A1 417这里有个很实用的简化计算技巧当 OVER8 0 时BRR 的数值本质上就是 fck / baud 四舍五入的结果。因为 BRR 整数部分 4 | 小数部分 × 16整体上就是在算 fck / (16 × baud) 放大 16 倍后取整约等于 fck / baud。所以你可以直接写uint32_t pclk 48000000u; // 以实际读取的 SWS 为准不要拍脑袋 uint32_t baud 115200u; uint32_t brr (pclk baud / 2u) / baud; // 四舍五入 USART1-BRR brr;这个写法在做裸机移植的时候特别好用一行代码搞定也不会在小数部分四舍五入上栽跟头。常见频率的 BRR 值可以列个表PCLK960011520048MHz0x1388 (5000)0x01A1 (417)16MHz0x0683 (1667)0x008B (139)8MHz0x0341 (833)0x0045 (69)算完 BRR 之后最好顺手验证一下误差。48MHz 下 BRR 417实际波特率 48000000 / 417 115108误差约 0.08%远在 ±2% 的容差范围内。但如果你用 8MHz 跑 115200误差会明显变大高波特率场景下就需要注意了。2.2 为什么一改系统时钟串口就崩这个问题的典型场景是这样的板子刚上电BootLoader 或者早期初始化代码用默认时钟把 USART1 调好了115200 通得很开心。然后在 main 函数里某段从别的项目抄来的代码把系统时钟从 HSI 切到了 PLL或者把 APB 预分频从 /1 改成了 /2。改完时钟之后USART1 的 BRR 还是原来那个值但 PCLK 已经变了波特率自然就偏了。还有一种更隐蔽的情况你开了 USB 或者其他外设CubeMX 为了满足约束条件自动把 APB 预分频调成了 /2PCLK 从 48MHz 掉到 24MHz。这时候你把代码生成出来如果没仔细看 HAL_RCC_ClockConfig 里给了什么分频系数就会拿着一套看起来正确的配置跑然后莫名其妙死在串口上。我的建议很简单所有外设的初始化必须放在系统时钟最终确定之后。在 C092 这种小芯片上我甚至建议把时钟配置做成一个独立函数在 main 最开头调用确定之后再去做 GPIO、USART、定时器的初始化。如果你中途真的不得不改时钟哪怕只是换一个分频系数也要建立一个改时钟必改 BRR的条件反射。这个坑我踩过不止一次每次都是同一个套路先怀疑代码逻辑查半天最后一看原来是 APB 预分频变了
