企业官网建设流程全解析

做低功耗项目的朋友，估计都经历过这样的“至暗时刻”：代码里加了低功耗逻辑，程序一跑，调试器就死活连不上了。我在 STM32H562 上就栽过一次，罪魁祸首就是标题里说的 Immediate standby mode。现象非常直接：微处理器（µP）彻底不可访问，ST-LINK 报错提示找不到目标，重新上电也没用，因为芯片一上电又立刻执行了进入待机的代码，看起来就像“每次复位都在自杀”。

这块芯片是 STM32H5 系列的 CORTEX-M33 内核，功能很强，低功耗模式也不少，但正是这个“立即待机”选项让我吃够了苦头。这篇文章我会把问题背景、原理、排查过程和最终的解决方案完整写出来，尤其是“为什么 Immediate standby 会让 µP 不可访问”“怎么把看起来变砖的芯片救回来”“正常量产应该怎么配置唤醒源”这三个问题。不管你是做电池供电的 IoT 节点、便携设备，还是只是想在项目里压一下待机功耗，这篇踩坑记录都值得看完。

1. 项目背景：Immediate standby 一开，芯片直接“失联”

1.1 项目需求与最初代码

当时我在做一个低功耗数据采集终端，主控选了 STM32H562。选它的原因很直接：主频够高，跑算法不费劲；外设丰富，传感器接口、串口、SPI 都有；而且作为 STM32H5 系列，低功耗模式做得比较细，待机电流可以做到很低。

需求也不复杂：设备平时睡觉，定时醒来采集一次传感器数据，再通过无线模块发出去，然后继续睡。理论待机电流目标是 5µA 以内，所以待机方案肯定要上 Standby 而不是 Stop。Stop 模式虽然唤醒快、RAM 内容不丢，但功耗还是会比 Standby 高一个量级，只有 Standby 能彻底关掉大部分电源域。

代码逻辑很简单，按照 CubeMX 生成的工程，进入待机前把外设关掉，然后调用 HAL 库的待机函数。问题出在我在 CubeMX 的电源管理配置里，直接勾选了 “Immediate standby mode”。这个选项看起来很省电，也确实省电，但带来的后果我一开始完全没想到。

1.2 现象：调试器连不上，µP 不可访问

程序烧进去之后，第一次运行是正常的，串口会打印进入待机前的日志，我用万用表量到待机电流确实很低，心里还挺高兴。但再想通过 ST-LINK 连上去看状态时，ST-LINK 报错：

Error: No target connected Error: Target not found

用 STM32CubeProgrammer 试也是一样，不管点 “Connect” 还是 “Connect under reset”，都连不上目标芯片。最尴尬的是，重新上电也一样：上电瞬间，芯片执行完复位向量，很快又进入了待机模式，调试器根本没机会把内核停下来。

这时候我才意识到，标题里的 “µP inaccessible” 是什么意思：µP 是微处理器单元，也就是 Cortex-M33 内核。在 Standby 模式下，内核电源都被切断了，调试口自然也就失效了。Immediate standby mode 更是把所有过程“压缩”到极致，软件只要把待机请求置位，电源控制器立刻断电，根本不给调试器留反应时间。

1.3 不只是开发调试的问题，量产也可能踩雷

很多人会觉得，这是不是只是“调试时代不好用”，量产时无所谓？其实不是。如果唤醒源配置得不对，或者代码一复位就进入待机，那么整块板子等于“上电即砖”。尤其是 Immediate standby 这种模式，对唤醒源要求很严格：要么用 WKUP 引脚拉醒，要么用 RTC 唤醒定时器，要么用复位唤醒。如果这三个都没配好，芯片就只能躺在待机状态里，外部怎么折腾都没反应。

我后来翻遍了参考手册和勘误表，才把整个逻辑理顺。下面先从原理讲起，搞清楚它为什么会“不可访问”。

2. 原理剖析：Immediate Standby 到底做了什么？

2.1 STM32H562 的低功耗模式全家桶

STM32H562 不是只有一种低功耗模式。官方手册 RM0481 里把低功耗模式分成几档，从浅到深大致是这样：

Standby 这条最关键：它不是单纯让 CPU 停下来，而是把内核供电的 VCORE 域直接关掉。所以内核没有电，就没有任何执行能力，调试接口也一起失去作用。这一点和 Stop 模式有本质区别，Stop 模式下内核仍由主稳压器供电，只是时钟停止，调试器还能通过 DAP 访问一部分寄存器；Standby 则是整个核心域都被断电了。

2.2 “立即待机”和“延迟待机”的区别

STM32H5 系列在 Standby 模式上有一个比较新的设计：进入待机时可以选 “Immediate standby mode” 和 “Delayed standby mode”。二者的关键差异在于，软件发出待机请求之后，电源控制器是“立刻”关闭 VCORE 还是“等一个安全时机”再关闭。

“延迟待机”模式下，电源控制器会等总线空闲、内部存储器的访问结束、必要的状态都稳定之后，再真正断电。这个过程会给 CPU 一个“缓冲期”，也意味着调试器有更多机会在断电前完成连接和命令下发，开发期相对友好。

“立即待机”模式则不一样：软件一旦把待机请求位置位，电源控制器就直接进入待机状态，不再等待。从软件角度来说，几乎可以理解为“执行到那行代码的下一秒，整个芯片就断了电”。好处是功耗切得快，坏处就是，如果你没有提前把唤醒源、标志位、外部 IO 状态理清楚，芯片会瞬间“失联”，没有任何反悔余地。

我遇到的正是这种情况。工程里配置了 Immediate standby，代码一执行到进入待机的函数，内核立刻没电，调试口自然也就不存在了。之后哪怕是复位，只要启动代码又走到同一行，又会立刻断电，形成无限循环。

2.3 待机模式下µP不可访问的两个根源

把现象拆开看，µP 不可访问主要来自两个层面。

一是调试接口依赖内核时钟。Cortex-M33 的调试访问口（DAP）需要内核时钟和调试时钟才能工作，待机模式把内核域断电后，这两个时钟都没了，外部调试器自然拿不到任何响应。

二是待机后的唤醒路径大概率是“复位”。也就是说，芯片从待机唤醒后，并不是从原来的断点继续执行，而是从头走一遍复位流程。这对调试特别不友好：你以为能通过调试器把一个断点设在待机之前，但芯片已经被复位了，断点位置根本对不上；如果复位后马上又进入待机，那调试器连“抓启动瞬间”的机会都很难把握。

如果你在代码里把“进入待机”写在 main 函数最前面，比如一上电先做几个初始化，然后立刻进入待机，那么恭喜你，这板子基本就是“上电死”，跟烧录器之间只有极其短暂的连接窗口。我后来误打误撞能恢复，就是因为代码里进入待机前会先跑一个 2 秒的 LED 闪烁延时，让我有时间用 BOOT0 强制进系统 Bootloader。要是连延时都没有，那就真只能靠硬件手段强制擦除了。

3. 排查路径：从寄存器到唤醒源逐层找原因

3.1 第一件事：确认代码真的走入了待机

遇到这种问题，先别急着怀疑芯片坏了。用示波器或者万用表量一下 VDD 电流和 IO 电平，是判断芯片是否进入待机的最直接方法。

待机模式下，芯片整体电流会掉到几十µA甚至几µA，电源上的百毫安级电流基本消失。如果你发现电流还有几十mA，那说明芯片根本没进入真正的 Standby，可能是代码在进入待机前卡在某个外设初始化或者中断里了。反过来，如果电流确实很低了，但调试器连不上，那就说明它确实进了待机，问题方向就得转向“怎么唤醒”和“怎么避免上电后立刻再次进入待机”。

另外，可以用一个小技巧：在进入待机前把一个普通 GPIO 拉高，进入待机后这个引脚会失去驱动或者回到默认状态。这样即使调试器连不上，也能通过外部示波器看到程序执行到哪个位置了。我当时就是这么确认的，GPIO 很快从高电平掉到低电平，基本可以断定是执行到了待机请求之后。

3.2 唤醒源配置：最容易踩的坑

如果确认芯片在待机状态，但按唤醒信号没反应，问题大概率出在唤醒源配置上。STM32H562 的 Standby 模式支持以下几种唤醒源：

• WKUP 引脚（外部唤醒脚）
• RTC 闹钟 / 唤醒定时器 / 入侵检测 / 时间戳事件
• 复位脚 NRST
• 部分内部复位事件（看门狗、系统复位等）

WKUP 引脚配置时要注意极性。有的引脚是上升沿唤醒，有的是下降沿唤醒，需要看数据手册里的电气特性。CubeMX 里如果选了“Wakeup pin polarity”，要和实际按键电路匹配：按键默认拉高，按下拉低，那么应该选择下降沿唤醒；反过来接，就应该选上升沿。

RTC 唤醒则是另一个坑。RTC 时钟源可以用 LSE、LSI 或者 HSE 分频，但进入 Standby 后，并不是所有时钟都还活着。如果 RTC 时钟用的是 LSI，而低功耗配置里又把 LSI 关掉了，那么 RTC 根本走不了，唤醒定时器自然永远不会产生事件。我当时就是吃了个暗亏：以为 LSI 在 Standby 下会自动保持，结果手册里写得清楚，LSE 是后备域时钟，Standby 下保持；LSI 一部分配置下也会保持，但如果你在低功耗模式里显式关掉它，RTC 唤醒就失效。

建议：量产项目里做长睡眠唤醒，尽量用外部 32.768kHz 晶振接 LSE，然后配置 RTC 唤醒定时器。如果板子空间、成本紧张必须用内部 LSI，一定要仔细看参考手册里的电源域供电说明，确认 LSI 是否在目标低功耗模式下保持运行。

3.3 调试接口与DBGMCU的关系

很多人以为“只要在调试模式下用 DBGMCU 低功耗调试功能，就能在待机模式下继续访问芯片”，这是个误解。

STM32 的 DBGMCU 控制寄存器里确实有 DBG_STANDBY、DBG_STOP、DBG_SLEEP 这类位，可以让调试器在低功耗模式下保持连接。但这类位对 Stop 模式比较有效，对 Standby 模式基本没用，因为 Standby 模式下 VCORE 域直接断电，DBGMCU 所在的调试域也跟着没电了。调试器能看到的只剩一个“死掉”的芯片内核。

如果你做的是带 TrustZone 的工程，还要注意 Secure/Non-Secure 调试权限。STM32H562 支持 TrustZone，如果芯片配置成了最高安全等级，调试口是默认被封锁的，那跟 Standby 无关，单纯就是调试权限问题。这个要点，我建议所有用 H5 系列做开发的人先查一眼参考手册的 Debug authentication 章节，免得关了安全模式还以为是低功耗模式搞的鬼。

3.4 选项字节、复位控制与“一次性”陷阱

还有一类非常隐蔽的坑，藏在选项字节（Option Bytes）里。

STM32H5 的选项字节里有一堆与复位、启动模式、读写保护相关的配置。对于待机模式，尤其要注意 “nRST_STDBY” 和 “nRST_STOP” 这类选项：它们决定芯片进入待机/停止模式时，NRST 引脚是否会被拉低产生复位信号。如果配置不当，你可能按下唤醒按键，NRST 引脚也跟着抖动，最后系统进入的不是“唤醒复位”而是“外部复位”，逻辑就全乱了。

另外，“一次性”陷阱指的是：有些配置或标志位在进入待机前设置后，唤醒后会保留某种状态，如果代码没有清除，会在每次唤醒后重新触发待机。比如 RTC 唤醒标志，如果唤醒后没有清 RTC_ISR 里的 WUTF/WUTF 相关位，某些库函数或中断处理可能认为唤醒事件还在，接着又去执行待机流程。这时候从外部看就像芯片“醒不过来”，或者“醒了立刻又睡”。

我当时踩的坑其实是另一种：代码里用了一个全局变量判断“是否需要进入待机”，但这个变量放在普通 RAM 里，Standby 唤醒后 RAM 内容已经不是原来的值，程序逻辑走到分支里，又调用了一次待机函数。看起来就是“无论怎么唤醒，只要唤醒后又跑到待机代码，就永远出不来”。

排查待机问题的核心思路，是尽量把“唤醒后的行为”和“第一次上电的行为”分开。很多项目只在第一次上电时初始化某些状态，待机唤醒后没有重新初始化，导致逻辑直接乱套。建议在唤醒后的入口处，先检查复位原因寄存器（RCC_RSR 或 PWR 里的复位标志），判断这次是“上电复位”还是“待机唤醒复位”，再决定执行哪条初始化路径。

4. 解决方案：把“变砖”的芯片救回来

4.1 恢复手段一：BOOT0 强制启动系统 Bootloader

如果你的芯片已经陷入“上电进待机”的循环，普通调试器连接已经失效，最可靠的办法就是强制从系统 Bootloader 启动，把 Flash 全部擦掉。

STM32H562 和大多数 STM32 一样，BOOT0 引脚电平决定启动地址。把 BOOT0 引脚接到高电平，然后重新上电，芯片会跳过用户 Flash，启动内置的 Bootloader。这时候用户代码没有执行，自然也不会进入 Standby，调试器或者 STM32CubeProgrammer 就能正常连上芯片。

具体步骤：

1. 断电。
2. 用跳线或杜邦线把 BOOT0 接到 VDD。
3. 上电，此时芯片运行在系统 Bootloader 模式。
4. 打开 STM32CubeProgrammer，选择 ST-LINK，连接。
5. 在 “Erase & Programming” 页面里执行 Full chip erase。
6. 断电，撤掉 BOOT0 跳线。
7. 再次上电，重新烧录用户程序。

这个操作听起来简单，但我在现场折腾了很久才成功。因为有些 STM32H5 的板子 BOOT0 引脚不是直连的，中间有电阻、跳线或电平转换，接触不良就会导致连接失败。另外，STM32CubeProgrammer 连接 ST-LINK 时，要把接口频率降低到 1.8MHz 或更低，待机模式下内部 RC 振荡器的启动过程不稳定，高速 SWD 容易握手失败。

4.2 恢复手段二：Connect Under Reset + 全擦除

如果不想动 BOOT0，或者板上没引出 BOOT0 引脚，可以试试 “Connect under reset”。

这个模式的原理是：ST-LINK 在连接时先把 NRST 引脚拉低，让芯片保持在复位状态，然后初始化 SWD 接口，再释放复位，并在极短的时间内尝试接管内核。如果代码从复位到进入待机需要的时间足够长，比如有初始化延时，这个方案就能成功。

在 STM32CubeProgrammer 里这样设置：

• 点击 “Settings” 旁边的箭头，进入 “ST-LINK configuration”。
• 连接模式选择 “Under reset”。
• Reset mode 选择 “Hardware reset”。
• 连接后立刻执行 “Full chip erase”。

但要注意，如果代码在复位后几乎不做什么就直接进入待机，那么 “Connect under reset” 也未必能抓住窗口。我实测下来，从释放复位到芯片执行第一条待机指令，最快可能只有几十微秒，普通 ST-LINK 很难保证每次都成功。这种时候，BOOT0 方案更稳定。

另外还有一个土办法：用镊子短接 NRST 电容或者 NRST 引脚到 GND，让芯片反复复位，同时在某个复位瞬间点击连接。纯属碰运气，不建议依赖，但紧急情况下偶尔能救回来。

4.3 代码层面：加自恢复开关与延时

救回芯片之后，更重要的是改代码，避免以后再陷进去。

我后来给自己定了一个规矩：开发调试阶段，一律先用 Delayed standby mode，别碰 Immediate；只有到量产前功耗验证阶段，才临时切到 Immediate，并且在进入待机的代码路径前加一个“自恢复开关”。

“自恢复开关”可以有多种实现方式：

• 上电后默认延时 3~5 秒，再进入待机。这样每次复位后，调试器有足够时间连接并停止内核。
• 检测某个 GPIO 状态，比如一个拨码开关或测试点，如果为高电平就跳过待机逻辑，方便调试。
• 检测串口接收缓冲区，如果调试上位机发送了“禁止待机”命令，就不进入待机。

我在字段里常用的是“延时 + GPIO 检测”组合：

void SystemPower_EnterStandbyWithCheck(void) { /* 调试/生产模式开关：测试点为高电平时不进入待机 */ if (HAL_GPIO_ReadPin(DEBUG_EN_GPIO_Port, DEBUG_EN_Pin) == GPIO_PIN_SET) { return; } /* 给调试器留窗口：进入待机前等待 3 秒 */ for (uint32_t i = 0; i < 3; i++) { HAL_Delay(1000); if (HAL_GPIO_ReadPin(DEBUG_EN_GPIO_Port, DEBUG_EN_Pin) == GPIO_PIN_SET) { return; } } /* 关闭外设，配置唤醒源，然后进入待机 */ HAL_DeInit(); /* ... 具体唤醒源配置见 4.4 节 ... */ HAL_PWR_EnterSTANDBYMode(); }

这段代码简单粗暴，但对于嵌入式现场调试特别有用。生产的板子不焊 DEBUG_EN 上拉电阻，引脚默认接地，依然正常进入待机；开发板则可以通过跳线直接封锁待机逻辑，让调试器从容连接。

4.4 正确配置 RTC 唤醒定时器

如果项目是定时唤醒，RTC 唤醒定时器是最常用的方案。我在 STM32H562 上最终可用的配置是这样：

1. 时钟源选择 LSE 外部 32.768kHz，确保待机时 RTC 时钟保持。
2. 初始化 RTC。
3. 配置唤醒定时器，周期根据自己的需求算。
4. 使能 RTC 唤醒中断（虽然 Standby 唤醒后不在中断里执行，但库函数会使用事件）。
5. 进入 Standby 前清一次唤醒标志。

代码大致是：

RTC_HandleTypeDef hrtc; void MX_RTC_Init(void) { hrtc.Instance = RTC; hrtc.Init.HourFormat = RTC_HOURFORMAT_24; hrtc.Init.AsynchPrediv = 0x7F; // 异步预分频 127 hrtc.Init.SynchPrediv = 0xFF; // 同步预分频 255 hrtc.Init.OutPut = RTC_OUTPUT_DISABLE; HAL_RTC_Init(&hrtc); // 唤醒定时器：32767 个 1Hz tick，约 4 秒 HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 32767, RTC_WAKEUPCLOCK_CK_SPRE_16bits); } void Enter_Standby_WithWakeup(void) { MX_RTC_Init(); // 清除待机唤醒标志 __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU); // 进入 Standby HAL_PWR_EnterSTANDBYMode(); }

需要注意，这个工程用的是 HAL_PWR_EnterSTANDBYMode()，默认对待机模式有基本处理，包括设置 SLEEPDEEP 位、清除 WFI 唤醒标志等。Immediate standby 的选择一般不在这个函数里，而是通过 CubeMX 生成的低功耗初始化代码，或者直接操作 PWR 控制寄存器完成。如果你的库版本比较老，进入待机前可以显式调用一下与“立即待机”相关的配置接口，再把 SLEEPDEEP 置位，最后执行__WFI()或HAL_PWR_EnterSTANDBYMode()。

用 LSE 时钟的一个小坑是：有些开发板没焊外部 32.768kHz 晶振，或晶振起振电容不合适，LSE 起振失败。这种情况 RTC 初始化会卡在HAL_RTC_Init()的超时检查里。如果发现芯片没进待机，反而是死在 RTC 初始化，先检查 LSE 是否起振，必要时用示波器量晶振引脚。

5. 实战验证：从进入待机到唤醒的完整流程

5.1 硬件连接和软件准备

我恢复板子的过程也算是一个标准的低功耗验证流程。硬件上准备这几样：

• 一块 STM32H562 核心板
• ST-LINK/V2 或者 ST-LINK/V3
• BOOT0 跳线（用于紧急恢复）
• 一个按键或者杜邦线，模拟 WKUP 输入
• 一个低功耗电流表，或者带电流分析功能的示波器探头

软件环境是 STM32CubeIDE + STM32CubeProgrammer。工程初始化时，我在 CubeMX 先把系统时钟配置好，然后只保留 LED、串口、按键三个外设，尽可能排除干扰项。

5.2 唤醒源选择与验证步骤

我同时验证了两种唤醒源：一种是用 RTC 定时 4 秒唤醒；另一种是用外部 WKUP 引脚唤醒。

WKUP 引脚的配置在 CubeMX 里对应 “System > PWR > Wakeup pin”。选择一个空闲引脚，设置极性为 “Low level” 或 “Falling edge”，把按键接在引脚和 GND 之间，默认状态下引脚内部上拉，按下按键时引脚拉低，即可触发唤醒。

验证流程我按下面几步走：

1. 先烧录一个不带待机功能的测试程序，确认 LED、串口正常。
2. 把测试程序改成“初始化完成后等待按键，按下进入待机”，烧录后按一下按键，观察电流是否骤降。
3. 把待机唤醒源配置成 RTC 定时唤醒，烧录后等待 4 秒，观察电流是否出现一个唤醒尖峰，然后再降下来。
4. 用 STM32CubeProgrammer 的寄存器窗口读一下 RCC_RSR 或复位原因寄存器，确认唤醒类型。

第三步很重要。如果唤醒尖峰出现，说明 RTC 事件确实发生了；如果没有任何电流变化，说明唤醒源根本没配通。

5.3 实测功耗与唤醒时间

在板子正常进入 Standby 之后，我用电流表串到 VDD 回路上量测，正常 Standby 模式下电流约 2~3µA（不算外部调试器供电）。切到 Immediate standby mode 后，电流差别并不大，因为两者最终都把 VCORE 关了，差就差在进入待机的“过程”上：Immediate 模式从软件发出请求到真正掉电只需要微秒级，Delayed 模式可能会多个几十微秒的缓冲。这个差异在毫安级平均功耗的测量中几乎看不出来，但对于功耗敏感产品，每一次唤醒-待机切换的能耗都值得抠。

唤醒时间方面，从外部触发 WKUP 到代码开始执行，我量到的结果是几百微秒到几毫秒不等，取决于唤醒后时钟启动方式和 Flash 等待状态。如果用了 Instant Wakeup 之类的快速唤醒特性，可以更快，但需要额外配置。

5.4 调试建议：开发期用延迟待机，量产期再换立即待机

经过这次折腾，我的使用策略变成了：

• 开发调试阶段：CubeMX 里用 Delayed standby mode，甚至直接用 Stop 模式调业务流程，把待机部分用宏隔离起来。
• 功耗验证阶段：程序运行稳定后，再把模式切到 Immediate standby，并逐个验证唤醒源。
• 量产阶段：如果要压功耗，才真正使用 Immediate standby，但必须在代码里加自恢复开关，且产品要有可靠的唤醒路径。

这个策略不是不信任 Immediate standby，而是它实在太“狠”了，调试器根本没有容错空间。低功耗开发本身就是从“能跑”到“能睡”再到“能醒”的过程，如果一开始就把最严苛的模式打开，遇到问题只能干瞪眼，效率很低。

6. 常见问题速查与避坑心得

6.1 常见问题表

我把这次遇到和调研到的典型现象整理成一个表，方便后面排查：

6.2 我的几条实操心得

第一，低功耗代码里，尽量把“唤醒后的路径”想成一次全新上电，不要把希望寄托在 RAM 数据上。你在待机前保存在普通 RAM 里的标志位，唤醒后大概率是随机值。公司里后来有同事遇到过“设备偶尔醒来不发数据”，最后查下来就是 RAM 里的状态变量在待机断电后变了。正确做法是把重要状态放在备份寄存器（Backup Register）里，或者每次唤醒后重新检查外部条件。

第二，Immediate standby 模式在官方参考手册里其实写得挺清楚，但工程师很少会逐字读电源管理部分。我的建议是，用 H5 系列做低功耗之前，先把 RM0481 里 “Power modes” 那一章从头翻一遍，特别是“standby mode”和“wakeup sources”两节，能省去很多后来猜谜的时间。

第三，一定要给板子留一个 BOOT0 跳线或者测试点。这不是可有可无的配置，而是低功耗板子的“救命稻草”。万一程序陷入上电进待机的循环，BOOT0 高电平启动系统 Bootloader 是唯一稳定可靠的恢复路径，尤其在没有调试器的情况下也能通过串口 Bootloader 擦除 Flash。

第四，别迷信“量产时不会用到调试器”。我这次就是觉得“反正产品烧录完就没人调试了”，所以在代码里没有留任何后门。结果烧录完发现固件版本号打错了，想重新烧一次，结果怎么都连不上，只能拆壳、焊飞线、强制 BOOT0。从那以后，我所有低功耗固件都会保留一个“调试模式”入口：上电时检测某个引脚，拉高就进入普通模式等待调试，拉低才允许进入待机。这个习惯帮我在后来几个项目里省了不少事。

第五，如果条件允许，功耗测量尽量不要用普通万用表电流档直接量，因为上电瞬间的浪涌电流可能会让万用表读出奇怪的值，也会影响芯片启动。最好用电流探头或者带 USB 供电控制的功耗分析仪，实在没有设备，至少用并联一个大电容的办法，把电源稳定下来再测。

最后再分享一个小技巧：在进入待机之前，把最后一个要打印的日志发出去，然后延时 5~10ms 再进行待机。这样板上如果接着串口调试模块，你能看到最后一条日志，确认程序执行到了哪一步。这个小延时不会影响实际功耗，但对于定位“是不是死在某项初始化里”非常有用。毕竟，低功耗模式下最可怕的不是“进不去待机”，而是“你觉得它进去了，其实它卡在别的地方再也出不来”。

这次踩坑基本上把 STM32H562 的 Immediate standby mode 整明白了。它确实是一个效率很高的低功耗特性，但用之前一定要想清楚唤醒源、复位路径和调试恢复手段。希望这篇记录能帮正在 H5 系列上做低功耗的朋友少走一段弯路。