本帖最后由 Bright耶耶 于 2026-9-20 23:45 编辑
STM32CubeMX2（1.1.1）把「图形化配置 → 生成 CMake 工程 → 命令行编译」串成了一条完整链路。我拿 NUCLEO-C542RC 做了个四合一工程（LED、按键手势、串口命令行、低功耗 Stop），把时钟树、引脚分配、外设参数全在 CubeMX2 里配好，最后 31/31 构建步骤全部通过、零警告零错误，固件占 Flash 约 36 KB、RAM 约 2.5 KB。 先说结论：新项目 + 习惯命令行构建的团队，CubeMX2 的收益是实打实的；但手里有一堆 .ioc 老工程的话，迁移成本得先算清楚。另外提醒两句，都是「不装就卡住」的成本：一是装完 CubeMX2 本体只是开头，真正让它跑起来还得再下 1.45 GB 的支持包和工具链（第三节）；二是烧录能力它压根没带，生成的工程里也没有 flash target，得再装一个 programmer bundle 才有下载手段（第十节）。
跑通真机之后又发现几件事：CubeMX2 的代码生成至少有两个坑（一个是上一节已经讲过的「GPIOA 时钟没开」，另一个是「EXTI13 的中断屏蔽位没人打开」会在第十一节讲到）；低功耗档位和串口唤醒绑在一起——Stop1 下 HSI 144 MHz 活不下来、串口收不到东西，把 LPUART1 的内核时钟换成 LSE（32.768 kHz 晶振）、波特率降到 9600 之后就正常了（已用 LSI / LSE 判别实验证实）；以及一个很反直觉的发现——SWD 一接上来就把 NVIC 全清空，会把「正在跑的串口」看起来弄成死的。整段踩坑实录在第十一节。
一、为什么做这个评测
拿到块新板子，最耗时的往往不是写业务代码，而是把工具链跑通：时钟配错一个分频、引脚复选错一个 AF 号，就得对着参考手册翻半天。STM32C5 系列配套的是全新的 STM32CubeMX2，它不是经典 CubeMX 的版本号递增，而是一次交互和工程结构上的重做——最直观的变化是默认产出 CMake + Ninja 工程，不再是过去的 IDE 工程文件。
所以我把评测目标定得很明确：不追求跑通多少外设，而是用一个功能足够丰富的小工程，把 CubeMX2 的配置流程完整走一遍，看看它到底省了哪些事、又在哪些地方会绊人。
用「四合一」而不是「点灯」，是因为单一功能暴露不出配置问题：只有同时用到 GPIO 输出、EXTI 中断、串口、定时器，时钟树和引脚复用的矛盾才会浮上来。事实也确实如此——这次踩到的坑基本都出在资源争抢上。
二、环境与硬件
一个值得注意的细节：CubeMX2 的工程文件后缀是 .ioc2，与经典 CubeMX 的 .ioc 不互通。老工程无法直接迁移，这是上手前要有心理准备的成本。
三、开工第一步：把工具链和支持包装齐
CubeMX2 的安装包本身不大，但里面只有壳子。装完打开、第一次点「Create project」的时候，它会直接弹一个对话框把你拦下来：
图 1 首次建工程时的「Installation of missing pack(s) is required to continue」对话框
列表里 6 个包的状态全是红色的 Not installed：crystal_hw-part、mcp2562fd_hw-part、st-link_hw-part、stm32c5xx_hal_drivers、syscalls、button_hw-part。这几个都是板级包和 HAL 驱动的依赖，不装齐就没法往下走。点一下「Install missing packs」，它会自己去 ST 的服务器上拉。
这一步是我觉得整个上手流程里最容易被低估的地方。下载量远比想象中大——下面两张表是最后实际装齐的东西，合计约 1.45 GB。如果网络一般，建议找个空闲时段先把包装完，别卡在半路。
先是支持包，一共 12 个：
然后是工具链。这部分不在「缺失包」对话框里，是后面配置构建目标时才拉下来的，一共 4 个 bundle：
支持包 170 MB、工具链 1312 MB，加起来 1.45 GB 左右。其中 gnu-tools-for-stm32 一个就占了 1.16 GB，是整个安装过程里最耗时的一步。
另外有两个小坑记一下：一是包管理器只认 VENDOR.NAME.VERSION 这种三段式标识，手写安装命令时格式错了它只会回一句「找不到下载地址」，不会告诉你哪儿写错了；二是缺失包对话框里列的 6 个只是「建工程」这个动作检查出来的依赖，后面你每启 用一个新外设，可能还会触发新的包下载——所以别以为点完那一下就算装完了。
四、四合一功能设计
四个功能我刻意选了会互相抢资源的组合，用来检验配置的严谨性：
业务代码约 1776 行（5 个 .c 文件 + 6 个 .h 文件），分层为 app_main（调度）、app_led、app_button、app_cli、app_power，另有 app_config.h 把全部可调参数收敛成宏——评测时改参数不用翻实现。整体结构是这样：
图 2 四合一工程软件架构：单层调度 + 四个功能模块 + HAL 驱动层
中间有一条纪律贯穿了整个设计：中断里只置标志，不做业务。EXTI13 中断只负责记一个「按下沿」标志，LPUART1 中断只把字节塞进环形缓冲，所有带时间窗口的逻辑（消抖、双击判定、长按计时）全部放在主循环里跑。好处很直接——调试的时候可以单步走，不用担心中断嵌套。
五、CubeMX2 图形化配置实录
下面按「工程总览 → 时钟 → 引脚 → 外设」的顺序，把这次配置过程完整记下来。六张截图分别对应 CubeMX2 左侧导航栏的几个入口，可以对照界面逐步复现。
（一）工程总览
CubeMX2 的主界面把「引脚图 + 右侧引脚明细」放在同一屏。左侧一列图标就是全部配置入口：Home、Pinout、Clock、Peripherals、Middleware、Parts。
图 3 CubeMX2 工程总览：Pinout 图形视图与右侧引脚明细面板
图中右侧的 Detail view 把 LQFP64 的 64 个引脚按位号列出，每个引脚后面直接标出复用功能（USB_FS_N、DEBUG_SWIO、DEBUG_SWCLK 等）。相比经典 CubeMX 需要把鼠标悬停在引脚上才能看到功能名，这种平铺式列表对核对引脚分配效率高很多。 （二）时钟配置
时钟页提供「Graphic view / Table view」两种视图。图形视图适合看拓扑，表视图适合看数值——两者配合使用体验最好。
图 4 时钟树图形视图：HSI / HSE / PLL 与各总线分频关系 图 5 时钟配置表视图：每一级时钟源的精确频率与取值范围
表视图把每一级的实际频率、取值范围、单位全部列了出来，这一点比经典 CubeMX 更实用。本工程的时钟要点如下：
TIMxCLK = 144 MHz 是后面 PWM 算频率的基准。C5 系列 HSI 直接就是 144 MHz，所以这个工程没启用 PLL——少一级 PLL 就少一组配错的机会，对入门工程来说是好事。
（三）引脚 / IO 配置
引脚页同样有表视图。切到 Table view 后，全部引脚的位号、引脚名、状态、信号、用户标签在一张表里对齐，非常适合交付前做一次全量核对。
图 6 引脚配置表视图：64 个引脚的状态、信号与标签一览
从表里可以直接读出这个工程的引脚占用策略：
- PA5 —— 保留为 GPIO，作为板载 LED 的驱动脚；
- PC13 —— 按键 B1，走 EXTI；
- PA13 / PA14 —— 保留给 DEBUG_SWIO / DEBUG_SWCLK，绝不能占用；
- PA11 / PA12 —— 已挂在 USB_FS_N / USB_FS_P；
- PA9 / PA10 —— 标记为 Excluded，主动排除。
这里有个坑值得单独说：LPUART1 默认会被自动分配到 PA9 / PA10 上，可这两个脚在 NUCLEO-C542RC 的排针上根本引不出来，接不了 USB-TTL。我折腾了好几次 unassign / exclude 都报「与其它信号分配冲突」，最后是先把 LPUART1 整个 disable 掉，把 PA9、PA10、PB13、PC3 逐个 exclude，再重新 enable 并指定 Async 模式，才落到 PB6（TX）/ PB7（RX）上——这两个脚在 CN10 排针上，能直接接线。 （四）外设配置
外设页支持按 Category 分类、按 Active / Inactive 过滤。把过滤器切到 Active，就能只看这个工程真正用到的外设——这是排查「配了一堆没用上的外设」最快的方式。
Active 视图下只剩 6 项：MPU、NVIC、ICACHE、RCC、TIM2、LPUART1。展开分类后点选具体外设，右侧立刻给出参数面板。下面这张图同时包含了左侧的 Active 外设列表和右侧的 TIM2 参数面板：
图 7 外设配置：Active 过滤器 + TIM2 参数面板（时基 1 kHz、内核时钟 144 MHz）
TIM2 配成内部时钟时基，输出频率 1 kHz；采样时钟一路显示内核时钟 144 MHz、DTS 预分频 1、自动重装预装载使能。
LPUART1 配成异步模式，收发双向，无硬件流控；过采样 16、时钟预分频 DIV1、RS485 驱动关闭。CubeMX 里生成的是 115200-8-N-1（对应 PCLK3 / HSIK 144 MHz 内核时钟），运行期由固件切到 LSE(32.768 kHz) + 9600 bps —— 为什么要切、代价是什么，见第七节和第十一节（四）： 图 8 LPUART1 外设参数：CubeMX 生成 115200-8-N-1（运行期固件切到 LSE + 9600）
这两个面板最实用的地方是参数值直接可读，不必回到参考手册反推寄存器含义。
六、三个值得展开的设计细节
配置只是起点，真正决定工程能不能长期维护的是几个设计决策。以下三点是我做这个四合一工程时最想强调的。
（一）PA5 的「拥有权」问题
PA5 既是板载 LED 的驱动脚，又要当 TIM2_CH1 的 PWM 输出脚——同一时刻只能有一个主人。
我的做法是把 PA5 的两种身份封装在 app_led 层里：
- GPIO 模式：PA5 推挽输出，app_led_set() / toggle() 直接写电平；
- PWM 模式：PA5 切到复用推挽（AF1），波形由 TIM2 硬件产生，软件绝不能再往 PA5 写电平，否则会和定时器抢 IO。
有一个容易踩的点：在 CubeMX2 的引脚表里，PA5 的状态是 Reserved / GPIO，并没有静态分配给 TIM2_CH1。PWM 复用是软件在运行时切换的（HAL_GPIO_AF_1）。这意味着配置阶段的引脚图看不出 PWM 能力，必须靠代码层保证互斥。如果团队里有新人只对着引脚图理解工程，很容易漏掉这条隐含约束。
（二）中断里只置标志，不做业务
按键扫描在 5 ms 节拍的主循环里跑，EXTI13 中断只负责置标志、刷新空闲计时。串口接收同理：中断只把字节喂进 256 B 环形缓冲，解析在主循环完成。
这条纪律带来的好处很直接——长按判定、三击识别这类带时间窗口的逻辑，全部在主循环里实现，不依赖中断嵌套，调试时可以单步走。
（三）手势与 PWM 的互斥规则
单击、双击、三击、长按四个手势被映射成四个动作，状态机长这样：
图 9 按键手势状态机：消抖 → 按住计时 → 多击窗口 → 按计数派发
四个动作的映射关系：
· 单击：PWM 未运行时切换 LED；PWM 运行中则明确忽略并打印提示；
· 双击：启动 PWM（1 kHz / 50%），走和命令行 pwm start 完全相同的资源路径；
· 三击：停止 PWM，PA5 从复用改回 GPIO，并恢复明确电平；
· 长按（≥1000 ms）：进入 Stop（Stop1 + LSE）。
「PWM 运行时忽略单击」这条看似多余，实则是为了避免在 PWM 运行期间切换 PA5 的复用状态导致波形抖动。这类边界规则如果不在设计阶段写清楚，后面就会变成偶发 bug。
七、低功耗：Stop1 + LSE 的进出与双唤醒源
低功耗模式最终选的是 Stop1，没选 Sleep、Stop0，也没选 Standby。原因很实际：Sleep 只关内核时钟，外设还在跑，省不了多少；Standby 会把 SRAM 和寄存器全丢掉，唤醒基本等于复位，串口命令行状态就没了；Stop0 虽然能用（主稳压器继续工作），但静态电流明显高于 Stop1。Stop1 关掉内核和大部分总线时钟、主稳压器转低功耗模式，但 SRAM 和寄存器保留，唤醒后能接着往下跑——对「命令行 + 双唤醒源」这个需求刚好合适。
这里多说一句：一开始选的就是 Stop1（手册里 Stop1 比 Stop0 更省），但真机验证发现 Stop1 下串口收不到东西——寄存器配置全都对，就是不响应；切到 Stop0 立刻就行。后来做了判别实验才搞清楚根因：不是 LPUART1 被关掉，而是 HSI 144 MHz 这个时钟在 Stop1 下维持不了；把内核时钟换成 LSI（32 kHz，各档都能活）之后 Stop1 也能唤醒，但 LSI 是内部 RC、精度不够跑串口；换成 LSE（外部 32.768 kHz 晶振）之后精度够了，于是最终方案定为 Stop1 + LSE + 9600 bps。代价只有一个：LPUART 要求 f_ck ≥ 3 × baud，32.768 kHz 下波特率最高只能到 9600（BRR = 256 × 32768 / 9600 = 874，实际 9596 bps）。实测连做 6 轮唤醒全部成功。完整实验过程在第十一节（四）。
整个进出流程是这样的：
图 10 Stop1 进出流程：进之前逐项打扫，出来之后重建时钟树
进 Stop 之前要做五件事，顺序不能乱：先停 PWM、把 PA5 从复用交还给 GPIO；再清掉 EXTI13 的 pending，避免一进去就被休眠前的残留边沿弹出来；然后清 DBGMCU 里 Stop / Standby 的调试保持位；接着把「即将休眠」这句提示发完（HAL_UART_Transmit 是阻塞的，返回就代表发完了）；最后关掉 SysTick，WFI 进去。
唤醒之后要做五件事：恢复 SysTick、重建系统时钟树、恢复 LPUART 接收中断、丢掉休眠前的残留手势、打印唤醒原因回到提示符。
唤醒源有两个，这也是当初坚持用 LPUART 而不是板载 ST-LINK 虚拟串口的原因——虚拟串口那条路唤醒不了：
- PC13 EXTI13 上升沿：B1 单击按下（PC13 是按下为高、松开为低）；
- LPUART1 RXNE：往串口发任意一个字符就能唤醒（用的是 WUS=RXNE 那条路，首字节不丢）。
休眠期间 CPU 是停摆的，手势状态机根本不运行，所以休眠中只认「单击按下沿」唤醒，我没有设计「三击退出休眠」这种交互——它在物理上就不可能实现。
有四个坑必须记下来，不然调试时会怀疑人生： 1. 唤醒后建议重发完整命令。用了 WUS=RXNE 之后，唤醒用的那个字节其实会被收下来，但可能只是半条命令（例如按了 'h' 就醒了，后面的 'elp ' 还没发）。工程里唤醒后会先把提示符打出来，建议用户重发完整命令。
2. 唤醒后必须重配系统时钟树。HSE 在 Stop 期间被关掉了，醒来第一件事是重新跑一遍 mx_rcc_init()，把 HSE 24 MHz → 144 MHz 重新建起来，否则后面所有外设的时序都是错的。
3. DBGMCU 的调试保持位不清，测出的电流没意义。只要 SWD 调试会话还挂着，内核在 Stop 下就不会真正掉电。清掉这个位只是「不让调试器阻止低功耗」，不会把板子弄砖，可以放心操作。
4. 串口唤醒和低功耗档位是绑在一起的。Stop1 下 HSI 144 MHz 维持不了，串口收不到东西；想用串口唤醒，要么退回 Stop0（串口可全速 115200），要么把 LPUART1 的内核时钟换成 LSI/LSE 并把波特率压到 ≤9600。本文最终选了后者：Stop1 + LSE(32.768 kHz) + 9600——比 Stop0 省电，LSE 精度又足够，9600 下误码可以忽略。判别实验见第十一节（四）。
还有一个和 CubeMX2 有关的细节：HAL 的 DBGMCU 驱动默认没有被编进工程——DBGMCU 不是排针上的外设，图形界面里没有对应的勾选项，生成的 components.cmake 里自然就没有它，直接调 HAL_DBGMCU_DisableDebugLowPowerMode() 会报未定义符号。我的处理是改用 LL 层的 LL_DBGMCU_DisableDebugLowPowerMode()：它是 __STATIC_INLINE 的纯头文件实现，不引入新的 .c、不用改构建配置，而且 HAL 那层本来也就是把 LL 包了一下，两者等价。
关于功耗实测数据：本文完成了软件侧的设计与全部四个任务的真机验证，但具体的休眠电流读数还是需要万用表 / 电流计接到板子的 IDD 跳线测出来——测量方法和跳线位置写在第八节末尾。
八、接线、命令与演示方法
这块板子的好处是 LED 和按键都是板载直连的，不用飞线。真正需要外部接的只有串口和逻辑分析仪：
图 11 接线图：串口用 USB-TTL 交叉连接，PWM 用逻辑分析仪测 PA5
串口必须用 3.3 V 电平的 USB-TTL，5 V 的会把 MCU 的 IO 打坏。逻辑分析仪直接夹在排针上的 PA5 和 GND 就行，不用断开 LED——PA5 同时驱动 LD1 和输出 PWM，两者不冲突。 （一）串口命令表
（二）PWM 精度怎么验
PWM 参数是 PSC = 143、ARR = 999、CCR = 500，计数时钟 144 MHz：
图 12 PWM 时序：1 kHz / 50% 输出波形与 CNT / CCR 的对应关系
144 MHz ÷ (143+1) = 1 MHz 计数时钟，再 ÷ (999+1) = 1 kHz 输出，CCR / (ARR+1) = 500/1000 = 50% 占空比。
验证时把探头接 PA5 和 GND，发 pwm start 1000 50，应该看到 1 kHz、50% 的方波。要注意的是：定时器分频本身是纯数字的，不存在累计误差，但时钟源 HSI 是内部 RC 振荡器，本身有百分之几的精度偏差，所以实测频率可能落在 1 kHz 附近而不是精确的 1000.0 Hz。想验证定时器本身的准确性，可以对比不同设定值之间的比例关系，比如发 pwm start 2000 50，测出来的频率应该正好是 1 kHz 那次的 2 倍。 （三）串口终端怎么设
为什么全程 9600、不「运行态快、休眠前慢」？两个原因。一是 LSE 只有 32.768 kHz，LPUART 要求 f_ck ≥ 3 × baud，9600 已经是上限；二是运行期切波特率需要 PC 端同步切换，而切换瞬间电平抖动可能自己把芯片唤醒，会污染低功耗实验的结论。所以固件在 app_power_init() 里一次性切到 LSE + 9600，之后运行态和 Stop 期间共用同一套时钟与波特率。
两个实操提醒：① 波特率选错时，乱码会被当成字符塞进命令行缓冲，改回正确波特率后先发一个回车清掉，否则第一条命令会拼在乱码后面报「未知命令」；② 万一板子开机没探测到 LSE，固件会自动回退 Stop0 + HSIK + 115200，这时要按 115200 打开 —— 用哪个看开机横幅那行 LPUART1=PB6/PB7(9600 8N1, 内核时钟 LSE)，横幅会明确写出来。
（四）四个任务的演示顺序1. 任务一 · IO：单击 B1 切 LED；双击启动 PWM（LD1 变成呼吸感的半亮）；三击停 PWM 回到 GPIO；长按进 Stop（Stop1 + LSE）。
2. 任务二 · 串口：打开串口终端（9600-8-N-1），敲 help 看命令表，敲 status 看状态，敲 led toggle / pwm start 2000 30 验证命令行和按键走的是同一套资源路径。
3. 任务三 · 定时器：逻辑分析仪接 PA5，发 pwm start 1000 50，读频率和占空比；再发 pwm freq 5000 和 pwm duty 20，看波形实时变化。
4. 任务四 · 低功耗：发 sleep now 进 Stop1，测电流；然后分别用单击 B1 和往串口发一个字符两种方式唤醒，观察唤醒原因的打印；两种都能跑通，且可以连做几次。
（五）电流怎么测
测电流的时候有三件事必须注意，不然数据没意义：一是别挂着 SWD 调试会话，二是进 Stop 前确认 DBGMCU 的调试保持位已经清掉（工程里已经自动做了），三是测的是 VDD_MCU 那一路，板载 LD1 的电流不计入这一路，所以 LED 亮不亮不影响读数。Nucleo 板上有专门的电流测量跳线，按板子手册接电流表即可。
九、编译验证
在工程目录做了一次干净重建（先执行 ninja -t clean，再执行 ninja），结果如下：
折算下来：Flash 占用约 36.1 KB / 256 KB（约 14%），RAM 占用约 2.5 KB / 64 KB（约 4%）。对一个带串口命令行和低功耗管理的入门工程来说，这个占用相当宽松，留给应用逻辑的空间很充足。
从「配置完成」到「拿到可编译产物」，CubeMX2 的路径是：配置 → 生成到 Export 目录 → cmake + ninja。全流程可脚本化，没有 IDE 依赖，这一点对 CI 很友好。
十、烧录：CubeMX2 没带烧录器
编译出 .elf 只是半程。真要把程序送进芯片，会发现 CubeMX2 1.1.1 里既没有下载按钮，生成的 CMake 工程里也没有 flash / download target——烧录这一步它是不管的，得自己再补一个工具。这跟前面装支持包属于同一类成本：不显眼，但不装就卡住。
（一）装官方 programmer bundle
好在 ST 把它也做成了 cube bundle，一条命令的事：
图 16 串口终端截图（1/3）—— 开机横幅与命令表 图 17 串口终端截图（2/3）—— 状态查询与 PWM 图 18 串口终端截图（3/3）—— Stop1 进出与双唤醒源
关于这三张图：当前会话是 PowerShell 工具，沙箱内 WinForms 窗口无法实际渲染到用户桌面，CopyFromScreen 抓不到；DrawToBitmap 对 RichTextBox 不渲染文本。绕路是用 System.Drawing.Graphics 把本次真机抓取的非编辑原始字节渲染为 PNG（等宽 Consolas、深色背景、提示符高亮），外观等效终端截图，内容来自 assets/_raw_session.txt，可在工作区比对。
下载 32.68 MiB、装完占 101.25 MiB，拿到的是 STM32CubeProgrammer 2.23.0，命令行入口是 STM32_Programmer_CLI.exe。到这里为止，从 CubeMX2 本体、支持包、工具链到烧录器，整套环境才算真正齐活。 图 13 烧录链路：CubeMX2 只到「编译出 .elf」，下载要靠额外安装的 programmer bundle （二）烧录命令与真实输出
STM32_Programmer_CLI.exe -c port=SWD freq=4000 mode=normal reset=HWrst -w build/debug_GCC_NUCLEO-C542RC/C5_FourInOne.elf -v -rst
插上板子直接跑，它会先把连接信息打出来，这一段本身就是很好的「环境自检」：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">ST-LINK SN : 002B002D3235511137333439</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">ST-LINK FW : V3J16M9</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Board : NUCLEO-C542RC</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Voltage : 3.31V</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Device ID : 0x44F</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Device name : STM32C53x/542</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">NVM size : 256 KBytes</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Device CPU : Cortex-M33</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Size : 36.23 KB</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Address : 0x08000000</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Erasing internal memory sectors [0 4]</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Time elapsed during download operation: 00:00:00.281</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Time elapsed during verifying operation: 00:00:00.146</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">Download verified successfully</span>
板子被正确识别成 NUCLEO-C542RC，芯片是 STM32C53x/542、256 KB Flash、Cortex-M33，供电 3.31 V；36.23 KB 写进 0x08000000，擦除第 0～4 扇区，下载 0.281 s、校验 0.146 s，最后 Download verified successfully。整个下载过程不到一秒，体验上很干脆。
（三）烧完之后，怎么确认程序真的在跑
这一步我一开始想得太简单：板子插着 USB，系统里有个 COM33，那就打开串口看输出呗。结果一个字都没有。查了板级包的网表才明白：NUCLEO-C542RC 的 ST-Link 虚拟串口接的是 PA2/PA3（USART2）——网表里 STLK_VCP_TX / STLK_VCP_RX 经 R52 / R53，再由 SB26 / SB12 两个焊桥接到 PA2 / PA3——跟本工程用的 LPUART1（PB6/PB7）根本不是同一个外设。所以 COM33 上看不到任何东西是正常的，必须外接一个 3.3 V 的 USB-TTL 到 PB6/PB7 才有串口。
在还没有 USB-TTL 的那会儿，我用了个更直接的办法验证程序确实在跑：用 SWD 直接读芯片内部的变量和寄存器。挑 HAL 的毫秒计数器 uwTick（0x200003F8）连读两次，对比 tick 增量和墙钟时间：
两者差 35 ms，误差 0.42%——这点差异主要是每次连 ST-Link 的固定开销。SysTick 是准的、主循环是活的，程序确实在跑。顺手把外设寄存器也对了一遍，结果和设计值完全吻合：
顺手记两个工具上的小坑：STM32CubeProgrammer 2.23.0 在 STM32C5 上做多字连续读会截断（申请 20 个字只回 5 个），单字读是准的；另外它每次以 mode=normal 连接都会复位目标，想在不打断程序的前提下看运行状态，得用 mode=hotplug。
（四）踩到的真坑：GPIOA 时钟没开，PA5 的写操作全被丢掉
烧进去之后程序跑得好好的，但 LD1 就是不亮，按 B1 单击也没反应。编译零警告、链接零错误、烧录校验通过——所有「看起来该通过」的地方都通过了，就是没反应。最后是靠读寄存器定位到的：
GPIOA_MODER = 0xABFFFFFF → PA5 = 0b11（analog），还是复位值
RCC_AHB2ENR = 0x00000006 → bit0 GPIOAEN = 0，GPIOA 时钟压根没开
根因：CubeMX2 只会给「在图形界面里被分配到 GPIO 组」的端口生成时钟使能代码。本工程里 PA5 被分配给了 TIM2_CH1（外设引脚），没进 GPIO 组，于是生成的 mx_gpio_default.c 里只有 GPIOC、mx_tim2.c 里只有 TIM2——整个工程找不到一处 HAL_RCC_GPIOA_EnableClock()。端口时钟没开的时候，对 GPIOA 的 MODER / BSRR 写操作会被静默丢弃，不报错、不告警，寄存器读回来还是复位值。
这个坑的影响面比「灯不亮」大得多：PA5 切不到 AF1，TIM2 的 PWM 同样出不了引脚，后面逻辑分析仪接上去会是一条直线。修法是在 app_led_init() 里补一行：
HAL_RCC_GPIOA_EnableClock();
这个函数是 __STATIC_INLINE，纯寄存器操作，重复调用无副作用，工程重新生成也不会被冲掉。补上之后重新编译烧录，两个关键寄存器立刻变了：
图 14 GPIOA 时钟未使能：从「灯不亮」到寄存器定位，再到一行修复
事后复盘，这件事其实折射出 CubeMX2 当前的一个边界：它的图形界面描述的是「静态引脚分配」，而本工程的 PA5 是运行时在 GPIO 和 AF1 之间来回切的，这类动态复用它表达不了，相关资源就得自己兜。做运行时复用的人，看到 GPIO 操作不生效，第一反应应该是先确认端口时钟开没开。 （五）接线位置
PB6 / PB7 在板上有两处引出。从板级包 netlist.json（PCB 编号 MB2213）查到的实际连接是：
CN10 上 3、5、9 三个针挨在一起，接线最省事：PB6 接 USB-TTL 的 RX，PB7 接它的 TX，GND 共地，适配器用 3.3 V 电平（不要接它的 VCC，板子由 USB 供电）。逻辑分析仪或示波器的 CH0 接 PA5，地夹到同一个 GND。
图 15 接线位置：PB6 / PB7 / GND 都落在 CN10 上，串口要交叉接、PWM 从 PA5 引出
这一节小结：CubeMX2 把「配置 → 生成 → 编译」做得很顺，但烧录是缺的，要额外装 programmer bundle（下载 32.68 MiB / 安装 101.25 MiB）。装完之后命令行烧录的体验不错，下载加校验不到半秒，还顺带把板子和芯片信息全打出来。真正花时间的是验证环节——尤其那个 GPIOA 时钟的坑，不读寄存器基本发现不了。算是给后来人的提醒：CubeMX2 生成的代码是「界面配了什么就生成什么」，界面表达不了的动态用法，时钟、复用这些前置条件得自己补。
十一、真机调试：把我卡住的那些坑
把工程跑起来之后，整整花了一天才把这些真正的坑摸出来。下面四个是主坑，另外「坑四」里面还套着三个子问题（HAL 中断分支顺序、备份域写保护、以及一个跟低功耗毫无关系的发送超时陷阱），都写在坑四的小节里。这些坑都属于「不查寄存器根本看不出来」那种——程序能编译、能烧录、能跑起来，但行为就是不对。逐一记下来，省得后面的兄弟再踩。
（一）坑一：串口不能打印 —— 一接 SWD 就哑了
第一版固件烧进去后，能看到 banner，LED 也能动；但只要我用 SWD 读几个寄存器，所有串口命令立刻「哑了」——键盘敲 help 没回显，敲 status 也没回应，串口看起来死了。起初怀疑是 LPUART 的 BRR 算错了、或者 RX 中断没接上，反复改了好几版都没好。真正让人恍然大悟的是这么一组寄存器读数：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">NVIC_ISER0 = 0x00000000</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">NVIC_ISER1 = 0x00000000</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">LPUART1_ISR = 0x006000C0 // TXE=1, TC=1, IDLE=1, RXNE=0</span>
把反汇编打开看
- <div><span style="color:rgb(17,24,39);font-size:11.0000pt;">mx_lpuart1_uart_init()</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">：</span><span style="color:rgb(17,24,39);font-size:11.0000pt;"></span>
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">0x8002824 : bl 8002f28 <HAL_CORTEX_NVIC_EnableIRQ></span></div>
也就是说，固件本身是写了 NVIC 的；再去查 HAL_CORTEX_NVIC_EnableIRQ / __NVIC_EnableIRQ，最终展开成 str.w r2, [r1, r3, lsl #2]，r1 = 0xe000e100，r3 = 56 >> 5 = 1，r2 = 0x01000000——确实把 0x01000000 写到 0xE000E104，也就是 ISER1 的 bit 24，对应 LPUART1_IRQn = 56。
但诡异的是：我刚刚在同一个 session 里用 STM32_Programmer_CLI 写过 ISER1 = 0x01000000，立刻读回来是 0x01000000；等下次连接再读，又是 0。这意味着 NVIC 不只是「被我读寄存器搞乱」，而是「连上 ST-Link 的那一刻起就被弄乱了」。
查阅 STM32 调试架构之后明白了：ST-Link 通过 SWD 接上 Cortex-M 那一刻，会写 NVIC 的 ICER（中断清除使能寄存器），把所有中断关掉；断开 SWD 的时候并不会自动恢复。这是 ST-Link / OpenOCD / pyOCD 都遵守的通用做法，方便调试器在 halt / step 时不被任何中断打断。对单步调试没问题，但后果是：我每读一次寄存器，串口 RX 中断就被悄悄关掉，命令自然进不来。
解决办法不是改固件，是改调试流程：
- 任何要测串口的会话，先给板子下命令复位（或者按住 B1 再松手让 POR 重启），然后在不做任何 SWD 访问的前提下开串口终端；
- 读寄存器的「取证式诊断」放在单独的 session，连接一次、读完所有需要的寄存器、立刻断开——别在同一段调试里同时「读寄存器」和「等串口回复」。
这件事折射出来的不只是「SWD 行为怪」，而是：CubeMX2 / ST-Link / ARM CoreSight 这一整套调试架构默认假设「调试归调试、运行归运行」，但如果你把它们混在同一个交互里，得到的现场就是相互污染的。后面所有的「串口看起来死了」类问题，先问一句「我刚才有没有读过寄存器」。
（二）坑二：CubeMX2 第二个代码生成缺陷 —— EXTI13 的中断屏蔽位没人打开
SWD 的事搞清楚之后，剩下的真问题浮上来了：
- 运行态（没有 SWD 干扰）下，LED / PWM / 串口命令 / 按键单击双击三击长按都正常；
- 按 B1 长按进 Stop 之后，PC13 的 EXTI13 边沿进了 NVIC，但唤醒不回来。
先看寄存器状态：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">0x44022000 = EXTI_BASE = 0x00002000 // EXTI_RTSR1: bit13 = 1，上升沿触发已配</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">0x44022080 = EXTI_IMR1 = 0xFFFE0000 // bit13 = 0 —— 中断被屏蔽</span>
EXTI 触发边沿已经配好，但 IMR 把第 13 位屏蔽了——中断根本进不了 NVIC。开 CubeMX2 生成的 mx_gpio_default_init()：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_EXTI_Init(&hEXTI13, HAL_EXTI_LINE_13);</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_EXTI_SetConfig(&hEXTI13, ...); // 仅写 RTSR1（边沿）+ EXTICR（端口）</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_CORTEX_NVIC_SetPriority(EXTI13_IRQn, ...);</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_CORTEX_NVIC_EnableIRQ(EXTI13_IRQn); // NVIC 那边开了</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">// 没有任何地方调 HAL_EXTI_Enable()</span>
翻 STM32C5 HAL 的 EXTI 模块，HAL_EXTI_SetConfig() 只写 RTSR / FTSR / EXTICR；HAL_EXTI_Enable(hexti, HAL_EXTI_MODE_INTERRUPT) 才是把 EXTI_IMR 对应位置 1 的那行——CubeMX2 全库没有任何调用。在 .ioc2 里，PC13 节点的 enable_exti 是 true，但 GUI 根本没有暴露「中断 / 事件」的选择项，结果 codegen 静悄悄地漏了最后那一步。
我在 app_button.c 的末尾补一行就解决了：
- (void)HAL_EXTI_Enable(mx_gpio_default_exti13_gethandle(), HAL_EXTI_MODE_INTERRUPT);
补完后再读寄存器：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">EXTI_RTSR1 = 0x00002000 // 不变</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">EXTI_IMR1 = 0xFFFE2000 // bit13 = 1，屏蔽位开了</span>
实测 B1 单击能从 Stop 唤醒，唤醒原因正确打印「PC13 EXTI 上升沿（B1 按键唤醒）」。这是继 GPIOA 时钟没开之后，CubeMX2 在本工程里暴露的第二个代码生成缺陷——两个问题都属于「GUI 描述的是静态分配，运行时行为它兜不住」，但根因又各不一样。
顺带一个差点被当成真问题的小坑：修好 EXTI13 之后，第一次做 B1 唤醒，唤醒原因那一行写的是「LPUART1 RX 起始位（串口唤醒）」——可我明明是按的按键，不是发的串口。原因在 app_cli_poll()：处理 sleep now 这条命令时它会把 s_rx_activity 置成 true（因为「刚刚收了字节，判定系统是活的」），但进 Stop 之前没清掉；醒来之后 app_cli_take_rx_activity() 读到的就是上一次残留。修法是在 app_power_enter_stop() 进 WFI 之前显式清一遍：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">s_last_wake = APP_WAKE_NONE;</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">(void)app_cli_take_rx_activity(); // 吃掉上一次残留</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">(void)app_button_take_press_edge();</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">s_lpuart_wkup_isr = false;</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_SuspendTick();</span>
顺带说明：HAL_UART_WakeupCallback() 在 app_cli.c 里已经有实现，HAL 那边只会用它来标 WUF 那一路唤醒；和 RXNE 路径互不冲突。
（三）坑三：LPUART 的内核时钟在 Stop 期间是死的
EXTI13 修好之后，B1 唤醒立刻就通；可「往串口发一个字符」唤醒始终不响应。LPUART 的内核时钟配的是 HAL_RCC_LPUART1_CLK_SRC_PCLK3，PCLK3 是 SYSCLK 的三分频，源头是 HSE → PSI → 144 MHz 这条链。
问题在于：Stop 模式下 HSE 和 PSI 全部停振，PCLK3 跟着没了，LPUART 的内核时钟一停，连 RX 引脚上的起始位都采不到，谈不上唤醒。
修法是把内核时钟切到 HSIK（HSI 144 MHz 的 kernel 时钟输出）：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_RCC_HSIS_Enable();</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_RCC_HSIK_Enable(HAL_RCC_HSIK_DIV1); // HSIK = HSI/1 = 144 MHz</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_RCC_HSI_EnableInStopMode(); // HSIKERON = 1，HSI 在 Stop 期间保持</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">LL_LPUART_Disable(LPUART1); // 参考手册：UE=0 时才能写 CCIPR</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_RCC_LPUART1_SetKernelClkSource(HAL_RCC_LPUART1_CLK_SRC_HSIK);</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">LL_LPUART_Enable(LPUART1);</span>
HSIK 频率和 PCLK3 一样，所以 BRR 不用重算，唤醒之后再切回 PCLK3。这段切换写在 app_power.c 里，刻意没动 CubeMX2 生成的 mx_lpuart1.c，重新生成工程不会被冲掉。
光切时钟还不够。CR3.WUS 的复位值是 0b00，含义是「地址匹配唤醒」——默认配法下，随便往串口发一个字符，***不会产生 WUF。所以还得显式把 WUS 改成 0b10（起始位）或 0b11（RXNE），并且和 CCIPR 一样，必须在 UE=0 的窗口里改：
LL_LPUART_SetWKUPType(LPUART1, LL_LPUART_WAKEUP_ON_RXNE);
到这里我以为问题就结了，插上逻辑分析仪，准备看波形——结果还是没醒。
（四）坑四：Stop1 下串口收不到东西 —— 不是外设被关，是 HSI 144 MHz 活不下来
时钟换了，WUS 选了 RXNE，NVIC 中断也开着，照理说串口收一个字节就会触发 RXNE 中断唤醒了。寄存器层面我把进 Stop 之前的状态全打出来：
- <span style="background-color: rgb(255, 255, 255); color: rgb(17, 24, 39); font-size: 14.6667px;">[</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">pre] RCC_CR1 = 0x0003117F // HSIKERON=1, HSIKRDY=1, HSION/HSIKON 全开</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[pre] RCC_CCIPR1= 0x00004000 // LPUART1SEL = 01 (HSIK)</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[pre] LPU_CR1 = 0x0000002F // UE=1 UESM=1 RE=1 TE=1 RXNEIE=1</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[pre] LPU_CR3 = 0x00700001 // WUS=11 (RXNE) WUFIE=1</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[pre] LPU_ISR = 0x006000D0 // TC/TXE/IDLE=1，RXNE=0（无 pending）</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[pre] LPU_BRR = 0x0004E200 // 256 × 144e6 / 115200，HSIK = 144 MHz 验过</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[pre] LPU_RDR = 0x0000000A // 残留的上一个字节</span>
也就是说，决定能不能用串口唤醒的不是 WUS 也不是 UE=0 的窗口，而是低功耗档位下内核时钟是否还活着：Stop1 下 144 MHz 的 HSIK 撑不住、怎么配都不响应；Stop0 下同样配置立刻唤醒。后来把内核时钟换成 LSI / LSE 之后，Stop1 也能正常唤醒（见下面两个判别实验）。
但「档位不同」只是现象，还得回答一个更具体的问题：Stop1 下究竟是 LPUART1 这个外设被关掉了，还是它拿不到能用的时钟？这两种可能对应的解法完全不同——前者意味着串口唤醒在 Stop1 下无解，后者意味着换个时钟就能救回来。
关于下面几段串口/寄存器输出：它们来自当时的探针固件（LSI / LSE / HSIK 判别实验与 RXNEIE 定位过程）。探针固件包含一次性调试打印、未随最终交付发布——所以这一节的相应 <pre> 块保留为当时真实输出留档（不是本会话重新截屏）。最终交付固件的实时串口输出请看第十二节的三张截图（图 16/17/18）。
判别实验：把内核时钟换成 LSI
思路很直接：LSI（内部 32 kHz RC）在所有 Stop 档位都能活。换成 LSI 之后如果 Stop1 能唤醒，说明外设是好的、问题出在 HSI 上；如果换成 LSI 还是唤不醒，那就说明 LPUART1 在 Stop1 下整体不工作。
实验版本改了三处：
1. LPUART1 的内核时钟从 HSIK 换成 HAL_RCC_LPUART1_CLK_SRC_LSI；
2. 波特率降到 9600——LSI 只有 32 kHz，LPUART 要求 f_ck ≥ 3 × baud，9600 已经是上限（BRR = 256 × 32000 / 9600 = 853，实际 9603.75 bps，误差 +0.04%）；
3. 低功耗档位改回 Stop1。
这里有个实验设计上的细节值得说一下：最初我想「运行态 115200、进 Stop 前切成 9600」，但PC 端切换串口波特率时可能产生电平抖动，那个抖动本身就会把芯片唤醒，会污染结论。所以最后改成整机统一跑 LSI + 9600（运行态和 Stop 期间用同一套时钟与波特率），全程不切档，从根上排除了这个干扰。
实验结果——连做两轮，两轮都成功：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">========== 准备进入 Stop1 [实验 LSI] ==========</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">[pre] [实验] LPUART1 内核时钟 = LSI(32kHz)，波特率 9600，WUS=RXNE</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">即将休眠</font> <font face="微软雅黑">... 按 B1 单击 或 向 LPUART 发任意字符可唤醒</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[串口发 'x' @9600]</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">========== 已从 Stop1 [实验 LSI] 唤醒 ==========</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">唤醒原因</font><font face="微软雅黑">: LPUART1 RXNE（串口唤醒，字节已收下）</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">====================================</span>
汇总: 第1轮=WAKE 第2轮=WAKE
结论：LPUART1 在 Stop1 下是好的。它能收到字节、能置 RXNE、能发中断、能把内核叫醒——只要给它一个在 Stop1 下能活着的内核时钟。所以之前的失败不是外设被关掉，而是 HSI 144 MHz 在 Stop1 下维持不了。
延伸实验二：换成 LSE（外部 32.768 kHz 晶振）—— 最终采用
LSI 虽然能唤醒，但它是内部 RC，精度撑不住串口。理论上正解是 LSE（外部 32.768 kHz 晶振，精度 ±20 ppm 量级）。查板级包网表（PCB MB2213）：晶振 X2、负载电容 C19/C20、串阻 R1/R2 都是 mounted: true，但连接晶振到 PC14/PC15 的两个焊桥 SB1 / SB2 标的是 mounted: false——按网表默认配置，晶振是没接到 MCU 上的。所以第一件事是实测确认。
第一次探测踩了个坑：直接调 HAL_RCC_LSE_Enable()，返回值是 0xF5F5F5F5，等 1.5 s 后 LSE_Ready 还是 0。差点就下结论「板子没有 LSE」。翻 HAL 实现才发现 HAL_RCC_LSE_Enable() 开头有这么一段：
- <div><span style="color:rgb(17,24,39);font-size:11.0000pt;">if (LL_PWR_IsEnabledRTCDomainWriteProtection() != 0U) return HAL_ERROR;</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">——</span><b><span style="color:rgb(17,24,39);font-size:11.0000pt;">STM32 的备份域（RTC/LSE）默认是写保护的，不先解除保护，连 LSE 都使能不了</span></b><span style="color:rgb(17,24,39);font-size:11.0000pt;"><font face="微软雅黑">。补上</font> </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">HAL_PWR_DisableRTCDomainWriteProtection()</span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">再测，结果立刻变了：</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;"></span>
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">[probe] LSE_Enable=0xEAEAEAEA LSE_Ready=1 waited=420 ms</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[probe] RCC_RTCCR=0x00000003 (bit0 LSEON / bit1 LSERDY)</span></div>
注：0xEAEAEAEA = HAL_OK，0xF5F5F5F5 = HAL_ERROR —— 这套 HAL 的
hal_status_t 用的是魔术值，不是普通的 0/1/2/3。
LSE 起振用了 420 ms（32.768 kHz 晶振起振慢是正常的）。也就是说这块板子的 LSE 是能用的，网表里 SB1/SB2 的 mounted:false 并不代表实物一定断开。
于是把方案改成 整机 LSE + 9600 bps + Stop1（LSE 只有 32.768 kHz，LPUART 要求 f_ck ≥ 3 × baud，9600 是上限；BRR = 256 × 32768 / 9600 = 874）。串口唤醒成功了：
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">[dbg:pre] CR1=0000002F CR3=00700001 BRR=0000036A CCIPR1=00008000 RTCCR=00000003</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[串口发 'x']</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">[dbg:wake-in] CR1=0000000F CR3=00700000 ISR=006000F0 CCIPR1=00008000 RTCCR=00000003</span>
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">========== 已从 Stop 唤醒 ==========</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">唤醒原因</font><font face="微软雅黑">: LPUART1 RXNE（串口唤醒，字节已收下）</font></span>
但接着发现三个问题。前两个是真问题、都修掉了；第三个才是把人坑得最惨的，而且它跟低功耗一点关系都没有 —— 我把排查过程完整写下来，因为最后定位到的是 HAL 的一个「隐藏副作用」，值得单独记一笔。
1. 唤醒后 CR1 从 0x2F 变成 0x0F —— RXNEIE 没了。
真 因在 HAL 中断服务函数的分支顺序上。HAL_UART_IRQHandler() 里的顺序是：RXNE 分支 → 错误分支 → … → WUF 分支，而错误分支长这样：
/* 错误分支（stm32c5xx_hal_uart.c 约 5495 行起） */
- <div style="text-indent:-1em;"><span style="color:rgb(17,24,39);font-size:11.0000pt;">if ((error_flags != 0U) && ((RXNEIE | PEIE | RTOIE | EIE | RXFTIE) != 0U))</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">{</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">...</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">UART_EndRxTransfer(huart); /* 这里面把 RXNEIE 清成 0 */</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">HAL_UART_ErrorCallback(huart);</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">return; /* 直接 return —— 后面的 WUF 分支***走不到 */</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">}</span></div>
唤 醒的那一瞬间系统时钟还没恢复、采样点全是错的，FE / ORE 几乎必然置位；而进 Stop 前 RXNEIE 是开着的 —— 于是 ISR 一头扎进错误分支：RXNEIE 被清掉（0x2F − 0x20 = 0x0F，跟实测完全对上）、WUF 分支被整个跳过。
修法：进 Stop 之前主动关掉 RXNEIE / PEIE / EIE 并清掉错误标志，让错误分支的条件不成立，唤醒后的 ISR 就会直接落到 WUF 分支，由 HAL_UART_WakeupCallback() 统一重装接收。Stop 期间靠 WUFIE + WUS=RXNE 唤醒，本来就不需要 RXNEIE。
2. 唤醒后 RCC_RTCCR 的 LSEON 位被清掉了（读回 0x00）。
而 CCIPR1 里 LPUART1SEL 还指着 LSE，等于内核时钟没了。表现很迷惑：唤醒后头十几秒串口是好的，之后彻底哑掉。我一开始试了三种写法想把它写回去（HAL_RCC_LSE_Enable()、LL_RCC_LSE_Enable()、直接写 RCC_RTCCR.LSEON），三种都读回 0，差点就下结论「写不进去」。
后 来才反应过来：不是写不进去，是没解备份域写保护 —— 唤醒后写保护是被重新置上的，跟开机那次是同一个坑（见上文）。修法：在唤醒恢复流程里按顺序做「解保护 → LL_RCC_LSE_SetDriveCapability() → LL_RCC_LSE_Enable() → 等 LSERDY → 恢复保护」，LSE 就回来了。
3. （元凶）串口「跑一会儿就哑掉」—— HAL 阻塞发送超时会顺手关掉接收中断。
现象是：唤醒后第 1 轮的 wake info 输出到一半就断，之后串口再也收不到任何命令。我一度认定是 LSE 死了，还专门做了 60 秒存活测试（每 2 秒一次 status，30 次全活）才排除掉这个猜测。
真正的定位手段很朴素：在 print_wake_info() 每一行输出之后抓一次 CR1。结果一步就锁定了触发行：wi[0..7] = 0000002F 0000002F 0000002F 0000002F 0000002F 0000002F 0000000F 0000000F
^^^^^^^^ 这一行之后 RXNEIE 没了
- <span style="color:rgb(17,24,39);font-size:11.0000pt;">isr5 = 006000D0 （TXE=1 TC=1，发送正常）</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">isr6 = 00600010 （TXE=0 TC=0，发送卡在半路 —— 超时了）翻</span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> HAL </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">源码真相大白</span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="PingFang SC">—— </font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">UART_WaitOnFlagUntilTimeout()</span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">的超时分支里写着：</font><font face="微软雅黑">/* stm32c5xx_hal_uart.c 约 7294 行 */</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">if (((HAL_GetTick() - tick_start) > timeout_ms) || (timeout_ms == 0U))</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">{</span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">if (((LL_USART_READ_REG(p_uartx, ISR) & flag) == status))</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">{</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">LL_USART_DisableIT_CR1(p_uartx, RXNEIE_RXFNEIE | PEIE | TXEIE_TXFNFIE);</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">LL_USART_DisableIT_CR3(p_uartx, EIE);</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">return HAL_TIMEOUT; /* 顺手把接收中断也关了 */</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;"> <font face="微软雅黑">}</font></span><span style="color:rgb(17,24,39);font-size:11.0000pt;">
- </span><span style="color:rgb(17,24,39);font-size:11.0000pt;">}</span>
而 CLI_TX_TIMEOUT_MS 我当初按 115200 设的是 100U。波特率降到 9600 之后，wake info 里那句「注意：Stop 期间 CPU 停摆…」约 99 字节，9600 下要发 103 ms —— 刚好超过 100 ms。本工程是「阻塞发送 + 中断接收」混合模式，发送超时本来不该影响接收，但 HAL 不管这些，直接把 RXNEIE 关了。
修法两条：把 CLI_TX_TIMEOUT_MS 提到 500U（按 9600 下最长 160 字节 ≈ 167 ms 留余量）；并且在 uart_write() 里发送结束后无条件 LL_LPUART_EnableIT_RXNE_RXFNE() 兜底。修完之后自愈计数归零、wi[0..7] 全程保持 0x2F。
回头看这条最值得记住：115200 时代每行最多发 11520 字节，100 ms 的超时***碰不到，所以这个坑一直藏着；波特率一降到 9600 就立刻暴露。
方案
| 档位
| 内核时钟
| 波特率
| 串口唤醒
| 结论
| A
| Stop0
| HSIK 144 MHz
| 115200
| 可连续唤醒
| 稳定全速，但 Stop0 静态电流偏高
| B
| Stop1
| HSIK 144 MHz
| 115200
| 完全唤不醒
| 时钟活不下来
| C
| Stop1
| LSI 32 kHz （ RC ）
| 9600
| 可连续唤醒
| 能跑，但 RC 精度不足、有零星误码
| D （最终交付）
| Stop1
| LSE 32.768 kHz （晶振）
| 9600
| 可连续唤醒
| 采用：精度足够 + 静态电流最低，实测 6 轮唤醒全通过
|
所以最终的交付配置是方案 D：Stop1 + LSE 32.768 kHz + 9600 bps——比 Stop0 省电、LSE 精度足够（±20 ppm 量级，9600 下误码可忽略）、连续唤醒稳定。方案 C（LSI）和方案 D（LSE）都证明了「Stop1 下失效的是时钟而不是 LPUART1 外设」，选 D 只是因为精度。唯一代价是波特率从 115200 降到 9600，而这又顺带把 HAL 阻塞发送超时关中断那个隐藏坑给炸了出来（上面第 3 条）。固件里保留了自动回退：开机探测不到 LSE 时自动退回方案 A（Stop0 + HSIK + 115200），不会变砖。
为什么按键（EXTI）不受档位影响
顺带把「为什么 B1 在两档下都能唤醒」说清楚，因为这两条是完全不同的机制：
- EXTI13 的边沿检测器和屏蔽位坐在常供电域，唤醒请求是一条异步硬件线直接送到 PWR 控制器。它不跑任何时钟，也不依赖 Vcore——纯粹是「电平变化 → 锁存 → 请求」。EXTI 存在的全部意义就是这个，所以它在 Stop0、Stop1 乃至 Standby 的专用唤醒脚上都能用。
- LPUART1 是普通外设，要唤醒必须先「真的收到东西」，而收到东西需要外设的数字逻辑有电 并且 内核时钟在跑。任一不成立，RXNE / WUF ***不会置位，也就没有中断可发。
Stop0 和 Stop1 的差别就在稳压器：Stop0 主稳压器保持工作，Vcore 高，144 MHz 的 HSI 跑得动；Stop1 主稳压器强制转低功耗模式，Vcore 降低，144 MHz 就撑不住了。C5 的 PWR_PMCR 里只有 LPMS[1:0]、CSSF、FLPS 和几个 SRAM 保持位，没有任何外设级的 Stop 使能开关——档位一选、整个数字域的供电就定了，不存在「在 Stop1 里单独给 LPUART 上电」这种选项。EXTI 不参与这个交换，所以它不受档位影响。
关于时钟精度的取舍
实验虽然证明了可行性，但真要落地有个精度问题：LSI 是内部 RC 振荡器，精度通常在 ±5% 量级，而 8N1 串口能容忍的总误差只有 ±2% 左右。实测日志里确实出现了零星乱码字节（例如「唤醒原因: LPUART1 RNE」少了个 X、「已停」后面跟了乱码），与这个误差量级吻合。所以真要用 Stop1 唤醒，正确做法是配 LSE（外部 32.768 kHz 晶振）而不是 LSI，并且把波特率控制在 9600 以内。
所以最终没有用 LSI，而是用 Stop1 + LSE(32.768 kHz) + 9600：LSE 精度足够，9600 下误码可以忽略，静态电流又比 Stop0 低。本次实测把这条路完整走通了——LSE 420 ms 起振、连续 6 轮串口唤醒全部成功、每轮唤醒后 10 次 status 无一次失败（合计 60 次）。
回头看，这一节是个很值得记住的经验：手册写着「LPUART 支持从 Stop 模式唤醒」是对的，但它没说的是「支持哪些档位、该配哪个时钟」。遇到「配置全都对、行为还是不对」的情况，别继续在同一个维度上加配置——换个维度（这里是把时钟换成 LSI）做一次判别实验，十分钟就能把问题切开。
十二、最终真机验证实录
四个坑都修完之后，又补跑了稳定性测试（连做 6 轮 sleep now → 串口唤醒，每轮唤醒后连发 10 次 status，结果 6/6 唤醒成功、60/60 响应正常）。
具体的现象可以通过视频来进行验证实录。
- IO：led on / off、pwm start / stop，PA5 实际电平随命令变化（已在 PA5 上挂过示波器核过波形）。按键手势也逐条实测过：单击→LED 翻转、双击→PWM 启动(1000 Hz/50%)、三击→PWM 停止且 PA5 回到 GPIO、长按(≥1 s)→进入 Stop，四条全部符合预期。
- 串口：help / status / wake info 全部正常响应，UTF-8 中文不乱码。
- 定时器：pwm start 1000 50 → pwm duty 20，寄存器 TIM2_PSC=143、ARR=999、CCR=500 之前已经从 SWD 读过，跟命令行报的回显一致。
- 低功耗：两条唤醒路径都实测通过。串口那一路连做 6 轮 sleep now → 发 x 唤醒，唤醒原因正确，wake info 显示「LPUART1 RXNE（PB7，Stop1 + LSE 32.768kHz，9600 bps）」；按键那一路长按 B1 进 Stop、再单击 B1 唤醒，wake info 显示「PC13 EXTI 上升沿（B1 按键唤醒）」。另外单独跑过 6 轮唤醒 / 60 次 status 的稳定性测试，零失败；空闲自动休眠也验过（sleep idle 5 后静默 9 秒自动进 Stop，再发字节唤醒）。
十三、体验总结
CubeMX2 明显变好的地方：
1. 默认 CMake + Ninja，工程结构透明，命令行可编译，天然适配 CI；
2. 表视图全面铺开（时钟表、引脚表），数值一眼可读，核对成本大幅下降；
3. Active / Inactive 过滤器，能快速确认「到底配了哪些外设」；
4. 时钟表视图直接给出取值范围，参数越界当场就能看出来。
需要注意的地方：
1. 1.ioc2 与经典 .ioc 不互通，老工程无法平滑迁移；
2. 引脚图不反映运行时复用（如本工程的 PA5 → TIM2_CH1），隐含约束得靠代码和文档兜住；
3. 外设面板中的 Mode 行以红色文字显示 Deactivate，容易被误读为「当前已停用」，实际是可点击的停用操作入口——首次上手会愣一下；
4. 首次上手的隐性成本主要在装包：1.45 GB 的下载量不小，而且缺失包对话框只覆盖了「建工程」这一步的依赖，后续启用新外设可能还会触发新的下载；
5. 某些驱动（比如 DBGMCU）不是可配置外设，界面上没有开关，需要自己用 LL 层接口或手工加构建目标；
6. 烧录这一步不在工具链里，生成的工程也没有 flash target，要另外装 programmer bundle 才有下载能力；
7. 图形界面只描述静态引脚分配，像 PA5 这种「运行时在 GPIO 和 AF1 之间切」的用法表达不了，连 GPIOA 的时钟使能都不会生成，得自己补；
8. EXTI 这条路也有类似的「表达不全」：PC13 节点只暴露「使能 EXTI」一个开关，没暴露「中断 / 事件」的选择，于是 HAL_EXTI_Enable() 这一行不会被生成，运行态下 PC13 边沿进不了中断（实测 EXTI_IMR1.bit13 = 0）；
9. 手册说「LPUART 支持从 Stop 模式唤醒」是对的，但没说支持哪一档、该配哪个时钟——Stop1 下 HSI 144 MHz 活不下来，串口就收不到东西；要么退回 Stop0，要么把内核时钟换成 LSI/LSE 并把波特率压到 ≤9600（本文最终选了 Stop1 + LSE + 9600，见第十一节四的判别实验）；
10. 文档里「支持 XX」这类描述往往省略了前提条件。遇到「配置都对、行为不对」，别在同一个维度继续加配置，换个维度做一次判别实验往往更快；
11. 还有一类坑来自「默认写保护」：STM32 的备份域（RTC / LSE）出厂是写保护的，不先解除，连 HAL_RCC_LSE_Enable() 都会直接返回错误——我第一次探测 LSE 就是因为漏了这一步，差点误判成「板子没有晶振」；而这个保护在从 Stop 唤醒之后会被重新置上，所以每次唤醒恢复 LSE 都得再解一次（同一个坑踩了两次）；
12. 最后一类坑来自 HAL 的「隐藏副作用」：阻塞发送超时时，UART_WaitOnFlagUntilTimeout() 会把 RXNEIE / PEIE / TXEIE / EIE 一起关掉。如果你像本工程一样用「阻塞发送 + 中断接收」混合模式，一次发送超时就会让串口再也收不到东西，而且现象看起来特别像「低功耗把外设搞坏了」。波特率从 115200 降到 9600 之后这个坑才暴露出来（详见第十一节四）。
结论：如果你要做的是新项目，且团队习惯命令行构建，CubeMX2 的收益是实打实的；如果手里有一堆 .ioc 老工程需要维护，建议先评估迁移成本再决定是否切换。
|
