STM32H562立即待机模式踩坑：芯片失联与恢复指南

做低功耗项目的朋友估计都经历过这样的“至暗时刻”代码里加了低功耗逻辑程序一跑调试器就死活连不上了。我在 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 里把低功耗模式分成几档从浅到深大致是这样模式CPU 状态外设状态RAM 保持典型唤醒源调试口可用性Sleep停止执行保持保持任意中断/事件基本可用Stop停止执行大部分可配置保持任意 EXTI/RTC有条件可用Standby断电大部分断电可选保留区WKUP/RTC/复位不可用Shutdown断电几乎全部断电不保持WKUP/RTC/复位不可用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 就能正常连上芯片。具体步骤断电。用跳线或杜邦线把 BOOT0 接到 VDD。上电此时芯片运行在系统 Bootloader 模式。打开 STM32CubeProgrammer选择 ST-LINK连接。在 “Erase Programming” 页面里执行 Full chip erase。断电撤掉 BOOT0 跳线。再次上电重新烧录用户程序。这个操作听起来简单但我在现场折腾了很久才成功。因为有些 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 上最终可用的配置是这样时钟源选择 LSE 外部 32.768kHz确保待机时 RTC 时钟保持。初始化 RTC。配置唤醒定时器周期根据自己的需求算。使能 RTC 唤醒中断虽然 Standby 唤醒后不在中断里执行但库函数会使用事件。进入 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/V3BOOT0 跳线用于紧急恢复一个按键或者杜邦线模拟 WKUP 输入一个低功耗电流表或者带电流分析功能的示波器探头软件环境是 STM32CubeIDE STM32CubeProgrammer。工程初始化时我在 CubeMX 先把系统时钟配置好然后只保留 LED、串口、按键三个外设尽可能排除干扰项。5.2 唤醒源选择与验证步骤我同时验证了两种唤醒源一种是用 RTC 定时 4 秒唤醒另一种是用外部 WKUP 引脚唤醒。WKUP 引脚的配置在 CubeMX 里对应 “System PWR Wakeup pin”。选择一个空闲引脚设置极性为 “Low level” 或 “Falling edge”把按键接在引脚和 GND 之间默认状态下引脚内部上拉按下按键时引脚拉低即可触发唤醒。验证流程我按下面几步走先烧录一个不带待机功能的测试程序确认 LED、串口正常。把测试程序改成“初始化完成后等待按键按下进入待机”烧录后按一下按键观察电流是否骤降。把待机唤醒源配置成 RTC 定时唤醒烧录后等待 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 常见问题表我把这次遇到和调研到的典型现象整理成一个表方便后面排查现象可能原因解决办法上电后立刻无法连接调试器代码复位后立即进入待机BOOT0 强制 Bootloader 后全擦除待机电流正常按唤醒键无反应WKUP 极性配置错误检查 PWR 唤醒引脚极性和外部电路RTC 唤醒不触发LSE/LSI 时钟源没配置或没起振改用外部 32.768kHz确认晶振和负载电容唤醒后马上又进待机RAM 标志位被清掉或 RTC 标志未清除用复位原因寄存器判断唤醒入口延时保护调试接口连接后极不稳定ST-LINK 频率过高待机恢复时钟不稳降低 SWD 频率到 1.8MHz 以下唤醒后外设状态不对Standby 唤醒后外设重新上电初始化没重置在唤醒复位路径重新初始化所有外设进待机前必须关掉外设吗不关也可以进但会增大漏电和唤醒干扰尽量 HAL_DeInit并关闭不必要的中断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 系列上做低功耗的朋友少走一段弯路。