RH850 DeepSleep 低功耗唤醒实战：INTP12 边沿检测与调试方法

简介：RH850_CS+_DeepSleep_Wakeup_INTP12 是一份面向嵌入式初学者的RH850微控制器低功耗唤醒示例工程，聚焦通过INTP12中断引脚将芯片从深度睡眠模式唤醒，适用于汽车电子、工业控制等场景中的低功耗应用开发。工程共176个文件，压缩包约397KB，源码以81个C程序与92个头文件为主，另含启动引导和C运行时初始化所需的2个汇编文件以及1个IDE项目配置文件，覆盖定时器、端口、I2C/RIIC、中断向量等常用外设模块，可帮助理解RH850底层驱动与唤醒流程。目前已有1125人学习下载，代码经过实际硬件验证，对新手尤其友好，能引导读者掌握深度睡眠模式下的中断处理、汇编与C混合编程、工程编译配置等完整开发链路，是学习RH850低功耗机制与中断唤醒的实用参考资料。

1. 一个只有 INTP12 能叫醒 DeepSleep 的嵌入式场景

调试低功耗节点的第一周，绝大多数时间不是在写业务逻辑，而是在回答一个问题：所有时钟都停了之后，芯片靠什么回来？RH850 系列进入 DeepSleep 后，主稳压器被切断，内核、Flash、以及绝大多数外设都失去时钟供给，此时片上 I2C 和定时器基本处于“电路还在、模块大脑已死”的状态，不可能指望它们产生中断。真正还能感知外部世界的，只剩少数异步边沿检测引脚，INTP12 就是其中之一。这篇内容围绕 RH850 在 CS+ 开发环境下进入 DeepSleep、靠 INTP12 外加一个下拉电阻唤醒的完整链路展开，把电源域划分、寄存器时序、唤醒路径和实测方法一次讲透。适合手里正拿着示波器和万用表调整机功耗的嵌入式工程师，也适合刚把 RH850 低功耗手册翻到 Low Power 章节还不确定从哪下手的开发者。

2. 为什么唤醒源偏偏选中 INTP12：DeepSleep 的掉电域与异步检测机制

2.1 DeepSleep 不是省电模式，是供电域切换

先纠正一个容易混淆的认知：RH850 的 HALT、STOP 和 DeepSleep 不是“同一件事的三个力度”，而是硬件上供电策略完全不同的三种模式。HALT 只是 CPU 核时钟被停掉，外设时钟还在跑，功耗降幅有限；STOP 状态下大部分外设时钟门控关闭，但稳压器仍在工作，掉电保存的内容范围比较大；到 DeepSleep（在 RH850/F1L 等型号的数据手册里常写作 DeepSTOP），芯片内部主稳压器关断，只有备份供电域继续保持。

备份供电域里有什么，决定了你能用什么唤醒。常见 RH850 系列保留区域包括备份 RAM（Standby RAM）、部分 I/O 端口的引脚状态锁存，以及专门为唤醒搭建的异步检测逻辑。换句话说，备份域的电路不依赖内核时钟，甚至不需要晶体振荡器运行，它靠芯片内部一个极低速的休眠时钟或纯电平检测电路持续监视唤醒条件。INTP12 的外部中断边沿检测正好就挂在这条异步链路上，引脚电平变化可以被模成唤醒脉冲，把关闭的稳压器重新打开。

这也是为什么选 INTP12 不是在“一堆 GPIO 里随便挑一个”。普通 GPIO 在 DeepSleep 下不带动边沿检测能力，即使引脚电平翻转，芯片也不会有任何反应。INTP12 需要满足两个条件：这个引脚本身支持外部中断功能，且所在端口在进入 DeepSleep 时没有被关闭供电。绝大多数代入式封装中，INTP12 满足这两个条件，才值得作为唤醒源候选。

2.2 INTP12 的唤醒链路：边沿极性、唤醒源使能、中断响应

INTP12 的完整唤醒链路从引脚电平变化到 CPU 恢复执行，其间要经过三道独立的开关，任何一道没打开，唤醒都只会停在半路。

第一道是引脚边沿检测。RH850 的外部中断模块通过 EGPI（边沿检测使能）和 EGPM（边沿极性选择）寄存器控制每个 INTP 通道的行为。EGPI 对应位置 1，引脚边沿检测才工作；EGPM 对应位决定是上升沿、下降沿还是双边沿。第二道是唤醒源使能。即使边沿检测已经出现有效电平跳变，如果 WUE（唤醒使能）寄存器里 INTP12 对应位没有被置位，这个事件不会进入唤醒逻辑，最多只能在正常运行模式下作为一次普通中断请求。这两道开关在逻辑上是独立的：EGPI 管“事件能不能产生”，WUE 管“事件能不能把芯片从 DeepSleep 拉回来”。

第三道才是 CPU 层面的中断响应。唤醒后，INTP12 对应的中断请求信号经过中断控制器仲裁，在 PSW 的中断使能位允许的前提下进入 CPU。这里有个容易忽略的点：前两道开关是电平到电平的组合逻辑，不依赖时钟，DeepSleep 下依然有效；第三道中断响应则是在系统重新起振之后才真正执行。

调试时如果发现“全速跑的时候按键有中断，进 DeepSleep 后就醒不过来”，先不要怀疑硬件，按上表把这三层逐一查过去，绝大多数问题出在第二层 WUE 没有配置。

2.3 为什么不用 I2C、定时器或外部 RTC 唤醒

搜索引擎里经常有 “rh850 i2c 唤醒” 之类的查询，但我们要清楚 I2C 硬件地址匹配唤醒依赖 I2C 模块自身的时钟，DeepSleep 下该模块的时钟域已经完全断电，根本不可能完成地址匹配。部分 RH850 型号的 RTC 唤醒需要独立的低功耗振荡器持续工作，虽然可行，但会额外增加数百纳安级别的功耗，而且 RTC 的时钟源一旦使用外部晶振，PCB 上还要多一颗 32.768kHz 晶体，成本和面积都不划算。

定时器唤醒则是一个更容易踩的坑：定时器模块在普通 STOP 模式下还能靠外部时钟或低速内部时钟工作，但进入 DeepSleep 后定时器的时钟源被切断，计数直接停在原地，永远等不到比较匹配。少数型号支持低速振荡器继续给定时器供时钟，但功耗会明显高于纯 INTP12 方案。相比之下，INTP12 不需要任何自持时钟，纯粹靠引脚边沿的异步检测，进入 DeepSleep 后额外功耗只在几十纳安量级。这就是大多数量产节点把按键唤醒、盖板打开唤醒、插入检测唤醒这类事件接到 INTP12 上的根本原因。

3. 在 CS+ 里把 RH850 武装到能进 DeepSleep 的最小工程

3.1 工程结构：代码生成器做初始化，低功耗序列必须手写

用 CS+ 新建 RH850 工程时，通常跟着向导选择芯片型号、调试器类型（E2 或 E2 Lite），然后自动生成包含启动代码、链接脚本和外设初始化框架的工程。CS+ 自带的代码生成器能省掉 GPIO、时钟、串口初化的手工劳动，但有一个边界要记住：代码生成器永远不负责生成进入 DeepSleep 的寄存器序列。原因很简单，代码生成器生成的初始化代码默认在 Reset 后从头执行，而唤醒场景下的恢复路径可能不需要完整的 C 运行时初始化。如果贪图方便把低功耗序列交给生成器，每次重新生成工程时都有被覆盖的风险。

我一般把低功耗相关代码放在一个独立文件sleep_mgmt.c里，编译选项里设置-O2，这不会影响寄存器操作的正确性，但优化器必须对系统寄存器的操作保持顺序。RH850 的系统控制寄存器很多是非缓存映射的，普通 C 语言写入在优化后依然会被编译成 STR 指令，不过仍建议给寄存器指针加上volatile限定，防止编译器把无关的连续写入合并掉。

3.2 INTP12 初始化：三步配好引脚和中断通道

进入 DeepSleep 之前，INTP12 必须工作在数字输入模式，且默认电平要确定。以常见的 RH850 系列为例，INTP12 通常与其他外设功能复用同一个引脚，初始化顺序如下方代码所示。注意具体的端口寄存器名因型号引脚定义不同而不同，但 PMC、PM、PPU 这三类寄存器在 RH850 各系列里命名一致。

/* INTP12 初始化：数字输入 + 内部上拉 + 下降沿触发 */ void intp12_init(void) { volatile uint32_t tmp; /* RH850 的系统寄存器大多有模式保护，写值前解除保护 */ REGC = 0x00U; /* 引脚功能先切到 GPIO，再选输入方向 */ P_pn.PMC &= ~(1U << PIN_INTP12); /* 关闭模拟/复用功能 */ P_pn.PM |= (1U << PIN_INTP12); /* 1 = 输入模式 */ P_pn.PPU |= (1U << PIN_INTP12); /* 打开内部上拉，防浮空 */ /* 边沿检测：EGPM 选下降沿，EGPI 打开使能 */ EGPM = (EGPM & ~(1U << 12)) | (1U << 12); EGPI |= (1U << 12); /* 恢复正常状态前重新使能保护 */ REGC = 0x01U; /* 打开全局中断 */ __EI(); }

逻辑说明：第一段解除 REGC 保护是因为 PMC、PM、PPU、EGPM、EGPI 这些寄存器在写保护生效时写入会被忽略；P_pn是端口数据结构体的引用，PIN_INTP12是引脚号宏，在不同封装上可能不同，替换成目标芯片头文件中的定义即可。PPU 打开内部上拉是为了保证按键未按下时引脚被钳在高电平，不会因为悬空产生随机边沿。EGPM 和 EGPI 的操作顺序有讲究：先设极性再开使能，避免在极性还没确定时就使能检测，捕获到一次不该有的跳变。

3.3 进入 DeepSleep 的寄存器序列与 SYNC 指令

进入 DeepSleep 不是在普通代码末尾调用一个.sleep()函数就结束，而是要通过一系列系统寄存器设置把芯片引导到目标模式，最后用一条 SYNC 指令让设置生效，时钟才真正停止。SYNC 的作用是刷新 CPU 流水线之前所有系统寄存器的写操作，RH850 的系统控制寄存器与 CPU 并行运行，不加 SYNC 直接进入低功耗模式可能让最后的 PSM 写入还没来得及到达寄存器，芯片退出的不是 DeepSleep 而是 STOP。

/* 进入 DeepSleep：只在 INTP12 下降沿到来后返回 */ void enter_deepsleep(void) { /* 进入前把所有唤醒无关外设时钟关断，具体位定义见各模块时钟门控寄存器 */ REGC = 0x00U; CGC_CLKCTL = CGC_CLKCTL & ~(EN_TAU | EN_I2C | EN_CSI); /* 端口防漏电：未用引脚统一配置为输出低，避免浮空 */ PORT_unused_all_low(); /* 使能 INTP12 作为唤醒源 */ WUE |= (1U << 12); /* 选择 DeepSleep 模式编码 0x03（DeepSTOP），具体以型号 PSM 字段为准 */ PSM = 0x03U; /* 关键：SYNC 指令，保证上面所有写在时钟停止前生效 */ __sync(); /* 正常情况下不会执行到这里，唤醒后从恢复路径继续 */ while (1) { /* 安全兜底 */ } }

这段代码中，CGC_CLKCTL只是示意，不同型号外设时钟门控寄存器结构差异很大，务必按所选型号的 Clock Generator 章节逐一关停使用不到的模块；对已经关闭时钟的外设，其寄存器读取结果可能变为不确定值，因此恢复路径中不要直接从这些模块的寄存器里读配置。SYNC 之后理论上芯片已经进入 DeepSleep，若 INTP12 唤醒后从同一条指令继续执行，那么while(1)是永远走不到的。

调试时要注意一个从 CS+ 中常遇到的假象：用 E2/E2 Lite 连接着芯片时，调试器本身需要维持调试时钟链路，部分 RH850 型号在 OCD（片上调试）有效时会拒绝进入深睡眠模式，或者刚进就立刻退出。遇到这种情况，先全速运行程序，再拔掉调试器通信线（保留供电）观察行为，不要误判成软件问题。

4. 唤醒恢复的代码路径、时序验证与三个高频坑

4.1 唤醒后第一条指令在哪：复位唤醒与中断唤醒的分岔

DeepSleep 唤醒后系统恢复到哪条指令继续执行，取决于芯片设计将唤醒事件映射为复位类事件还是中断类事件。这两条路径的选择直接决定恢复代码怎么写。

复位唤醒在多数量产的 RH850 低功耗设计里更常见。唤醒发生时芯片内部产生一个复位信号，CPU 从复位向量重新取指，启动代码和外设初化逻辑完整执行一遍，C 运行时环境（栈指针、BSS 清零、数据段拷贝）可靠重建。代价是整机恢复时间偏长，而且所有 RAM 中的临时数据都会按启动代码的初始化逻辑被重置。如果业务上只需要“系统可靠回到工作状态”，不依赖复位前的临时变量，复位唤醒是正确的默认选择。

中断唤醒则是唤醒后直接跳到 INTP12 对应中断服务函数，跳过启动代码。它的行为像一次异步中断，但此时的系统状态不是正常中断上下文可比的——全局变量初值不保证已经加载，被关闭时钟的外设寄存器在重新供电后需要重新初始化，栈空间是否有效取决于 RAM 在 DeepSleep 下有没有掉电。判断当前运行环境是否可用，最实用的办法是在进入 DeepSleep 前把唤醒路径要用到的一小块数据连同魔数写进处理器支持保持的备份 RAM，唤醒后先查魔数再走后续逻辑。

4.2 时钟恢复：不能假设唤醒后主时钟立即稳定

无论走哪条唤醒路径，有一个步骤都是绕不开的：等待时钟稳定后再访问外设。DeepSleep 模式下外部晶振停振，唤醒时的时钟恢复通常先依靠内部高速振荡器（HCO/MOCO）起振，然后再切换到外部晶振。如果代码里没有显式等待振荡器稳定标志位，外设时钟使能后立即配置寄存器，轻则丢配置，重则产生总线错误。稳定的等待逻辑用循环查询状态位实现：

/* 唤醒后的时钟恢复：先等 HCO 稳定，再切外部晶振 */ void recover_clock(void) { volatile uint32_t waited = 0; /* 内部 HCO 起振时间一般在几十微秒量级，查询状态位 */ while (!(CGC_OSCSTAT & HCO_STABLE_MASK)) { waited++; } /* 如果设计使用外部晶振，切换后必须再等待晶振稳定标志 */ CGC_CLKCTL |= USE_XTAL; while (!(CGC_OSCSTAT & XTAL_STABLE_MASK)) { waited++; } (void)waited; /* 超时保护：项目里可以在这里加计数值判断 */ }

代码里waited变量实际是给调试器看的：CS+ 调试时在第二行while处下断点，观察这个计数增加值可以估算出起振时间，从而判断选用的晶振负载电容是否匹配。如果 HCO 起振计数明显比手册典型值大一个量级，优先检查电源电压跌落情况和复位期间的电源去耦。

4.3 三个高频坑及对应排查手段

第三个坑在实测中最常被误报为“芯片有问题”。RH850 数据手册中的 DeepSleep 电流指标建立在所有引脚状态确定、调试接口关闭、供电电压稳定的前提下，而开发板上调试器接口的参考电平、目标板上的串口芯片漏电、甚至电源指示灯 LED 的限流电阻都会让整体电流高出几十倍。测量时逐项排除外部因素，电流数据才有对比意义。

4.4 用 CS+ 调试器确认唤醒路径的具体操作

CS+ 的调试界面里验证 INTP12 唤醒，我建议按这个顺序做：先把程序烧进 Flash，不要用 RAM 调试模式。RAM 调试时向量表和启动代码走的是调试器加载的临时镜像，与量产芯片从复位向量启动的时序不同，唤醒行为不具备参考性。

烧录完成后全速运行，在recover_clock()第一行、也就是时钟等待循环入口前设置断点。用信号发生器给 INTP12 一个下降沿，或者直接用杜邦线把引脚瞬间拉到地。如果系统停到断点上，说明唤醒链路已通；继续单步走，观察CGC_OSCSTAT状态位的变化，确认时钟恢复流程没有卡在某一个等待位。如果断点没被命中，先把 INTP12 的触发方式临时改成上升沿再试一次，排除边沿极性配置与硬件接法不匹配的问题。

控制好调试器连接状态这个变量：断点命中测试时调试器是接着的，这时 INTP12 触发的“唤醒时间”本身就受到调试时钟影响，脚本里测出的时间只作为功能验证，不能作为功耗和唤醒吞吐的基准数据。

5. 在备份 RAM 里留下唤醒门票，用 GPIO 翻转标定真实唤醒延迟

把验证再往前推一步，每个量产项目都应该在唤醒路径上留下两个可观测的痕迹。第一个是备份 RAM 里的魔数，第二个是 GPIO 翻转。

备份 RAM 的典型用法如下：进入 DeepSleep 之前，把关键状态帧（比如“当前处于待机态”“待机前 ADC 校准值有效”）连同魔数0xA5A5A5A5写入保持域 RAM；唤醒恢复代码的第一步就是读取并校验魔数。校验通过说明本次是唤醒事件，可以跳过完整初始化，直接恢复外设状态；魔数不匹配则代表这次是上电复位而不是唤醒，走一次冷启动流程。只需三五个判断语句，省掉的是“不知道该不该重做校准”带来的隐患。

/* 备份 RAM 魔数校验：区分唤醒恢复与冷启动 */ #define WAKE_MAGIC 0xA5A5A5A5UL #define WAKE_MAGIC_ADDR ((volatile uint32_t *)0x6FE00000UL) uint32_t check_wake_cause(void) { uint32_t rc = 0; if (*WAKE_MAGIC_ADDR == WAKE_MAGIC) { /* 保留 RAM 内容有效：这是 INTP12 唤醒后的恢复路径 */ *WAKE_MAGIC_ADDR = 0U; /* 消费掉魔数，防重复识别 */ rc = 1; } return rc; }

第二个可观测痕迹是 GPIO 翻转。进入 DeepSleep 前把一个空闲 GPIO 拉低，在系统恢复、时钟稳定的代码出口处再把它拉高。唤醒延迟 = 示波器上从 INTP12 下降沿到该 GPIO 上升沿的时间差，可以把硬件唤醒时间、振荡器起振时间和恢复代码执行时间合在一起量化。如果想拆解这三段的各自耗时，在recover_clock()的 HCO 等待循环前后各加一次翻转，就能把起振时间从总体时间中剥出来。把这一路 GPIO 挂到逻辑分析仪上，你会看到从 INTP12 下降沿到系统时钟输出稳定之间的那段时间，才是这个项目真正值得优化的地方。

本文还有配套的精品资源，点击获取