RH850 DeepSleep低功耗唤醒实战：INTP12配置与CS+工程要点

简介：面向RH850微控制器初学者的低功耗唤醒实战项目，基于CS+开发环境，演示通过INTP12中断引脚将芯片从Deep Sleep模式唤醒的完整流程。压缩包共176个文件，包含92个h头文件、81个c源文件、2个汇编启动文件及1个工程配置（.mtpj），代码按启动、驱动、中断、端口等模块划分，层次清晰；整个包仅397KB，轻量且便于研读。项目代码经过实际硬件验证，适合新手理解RH850的电源管理、中断向量配置与汇编/C混合编程。通过学习该项目，可掌握进入/退出Deep Sleep模式的寄存器操作、INTP12外部中断触发机制，以及从头文件到C源码再到启动汇编的工程组织方式。资源同时涉及串口、定时器、端口配置等常用外设，有助于系统建立嵌入式低功耗开发的基础认知。已有1125人学习下载，适合嵌入式入门者对照实践。

1. 为什么搞RH850的DeepSleep偏偏要选INTP12唤醒

在常电节点上做功耗控制，微安级的待机电流不是靠优化主循环能省出来的，而是必须让整颗RH850真正“睡过去”。DeepSleep就是这条路上最实用的一个档位：CPU停了、系统时钟停了、外设时钟也停了，但芯片还留着一个低功耗的唤醒检测电路，用引脚边沿就能把人叫醒。INTP12正是这套机制里最有代表性的外部中断唤醒通道。

但这里有个新手必踩的误区：你在普通运行模式下把INTP12的中断使能打开，引脚来了边沿能进ISR，这不代表你把它带进DeepSleep它还能把芯片唤醒。RH850的唤醒逻辑和普通中断控制器是两套流程，DeepSleep下真正起作用的是唤醒使能位，不是中断使能位。很多工程师在CS+里配置完中断、兴冲冲地睡下去，结果发现怎么都等不到醒来，就是卡在这上面。

所以这篇文章要从电源模式讲起，把RH850的DeepSleep唤醒链路拆开，落到CS+工程里的寄存器配置、PMDR切换序列、唤醒后的时钟恢复和标志判定，最后带一段实用的I2C低功耗巡检流程。适合正在用CS+调RH850低功耗的固件工程师，也适合刚接触该系列电源管理的入门者。

2. RH850的DeepSleep不只是一个低功耗睡眠，唤醒路径与时钟域要先分清

DeepSleep这个名字听着很直观，但实际踩下去，边界和代价比想象要细。先把这个模式在电源管理里的定位搞清楚，后续配置才有方向。

2.1 RH850电源管理模式里DeepSleep的定位与退出条件

以RH850/F1x系列为代表的汽车级MCU，电源管理模式通常包含正常模式、HALT、STOP、DeepSleep以及部分型号才有的DeepSTOP。HALT下CPU停转但外设时钟还在跑，适合轻量待机；STOP停了主振荡器，RAM保持，但一部分外设和调试相关逻辑可能还带电。DeepSleep往前走了一步，把外设时钟和系统时钟全面停掉，只保留低功耗所需要的唤醒电路和必要的RAM保持供电。而DeepSTOP是更极端的一档，主要面向长时间静态待机，代价是唤醒后大量模块需要重新初始化。

这里有个值得注意的设计原则：DeepSleep掉的不是“所有寄存器”。RAM内容大多保持，SFR里已配置的唤醒源信息也保持，所以唤醒后的代码能基本无缝地继续执行。但系统时钟是在唤醒后从低速源重新起振的，原来主循环里依赖PLL或外部主振荡器跑起来的外设必须重新切换时钟。理解了这一点，再回头看待机电流和唤醒时间，就不会被手册上的单点数字误导。

下表把DeepSleep和DeepSTOP放在一起对比，方便在实际方案里做取舍。这里的数据不是特指某一颗料，而是模式级的行为差异，具体参数以你手上型号的用户手册为准。

2.2 INTP12能成为DeepSleep唤醒源的硬件基础

INTP12属于RH850的外部中断引脚，编号不同但机制一致：引脚对应的边沿检测电路在DeepSleep下由独立的低功耗电源域供电，因此即使CPU和外设时钟都停了，引脚上的上升沿或下降沿依然能被硬件捕获。捕获之后不是像普通运行模式那样走INTC中断控制器去发ISR，而是直接在硬件上请求退出睡眠状态，启动时钟恢复流程，再让CPU回到正常的执行流。

所以这里要建立起第一层认知：INTP12的“中断功能”和“唤醒功能”是两条路径。中断功能归ICU/INTC管，唤醒功能归低功耗唤醒逻辑管。CS+代码生成器在配置R_Config_INTP12_Create这类函数时，多半只帮你把边沿检测和中断优先级写好了，不会自动把唤醒使能位也填上。新的RH850工程里，往往需要自己再补一段SFR操作，把INTP12的唤醒使能打开。如果漏掉这一步，就会出现“芯片睡下去，INTP12来了脉冲，测量引脚能看到边沿，但CPU就是不动”的诡异现象。

2.3 唤醒时间和平均功耗的权衡

DeepSleep的“唤醒时间”不是芯片单独决定的，而是由你的时钟树设计决定的。唤醒后首先要等主振荡器稳定，再切换PLL或分频目标。这个等待时间通常在几十到几百微妙量级，如果唤醒后还做I2C通信、看门狗重新定位之类，则软件还要额外花时间。反过来，DeepSleep省的功耗也不是一个静态值，而是看你在睡眠点和唤醒点之间的占空比。

我一般会在项目初期定下这样一个粗略公式：平均电流约等于（睡眠电流乘以睡眠时间 + 工作电流乘以工作唤醒时间）的一部分。如果INTP12唤醒很频繁，每次醒来只读一个寄存器就回去，那HALT模式加上外设时钟裁剪可能更划算；如果唤醒间隔秒级以上，DeepSleep的收益就非常明显。这个判断不是非黑即白，但能告诉你要不要继续往深调。核心思路是：把系统当做一个“睡眠为主、工作为辅”的设备来设计，而不是做完功能后顺手加一个sleep。

3. 在CS+工程里配INTP12唤醒的四个关键步骤

理清了DeepSleep的边界，下面进入CS+环境里的实操。这里按初始化、唤醒使能、进入睡眠、ISR处理四段来拆，确保每一步你都能在自己的工程里找到对应的配置位置或SFR操作。

3.1 第一步：配置INTP12的触发边沿与引脚复用

INTP12的触发边沿配置在不同型号上有略微差异，但本质上都是选择上升沿、下降沿或双沿作为有效唤醒事件。在CS+里打开代码生成器，找到对应引脚的外部中断配置，把INTP12分配到一个实际封装引脚上，并选择边沿触发方式。选边沿时要注意外部信号的静态电平状态，比如信号空闲时是高电平，唤醒脉冲是低电平，那就该选下降沿，否则上电瞬间可能直接触发一次非预期的唤醒。

/* 解除系统保护寄存器写保护 */ HW_PROTECT_UNLOCK(0x0F); /* 配置INTP12触发边沿：双沿，适合脉冲宽度不确定的唤醒源 */ INTP12EC |= 0x02U; /* 将INTP12引脚切换为外部中断功能 */ PM12 &= 0x0FU;

第一行是RH850特有的SFR保护处理。RH850对部分寄存器的写入有硬件保护，直接写会被忽略，必须先解锁。第二行设置边沿模式，第三行把引脚的端口模式切换为外设功能位。这样INTP12才真正具备边沿检测能力。配完后可以读一次INTP12的触发标志位做验证，用手碰一下引脚看标志是否变化。

3.2 第二步：把INTP12打开为DeepSleep唤醒源

这是新手最容易少做的一步。边沿检测配置完成只代表该引脚能识别外部信号跳变，但DeepSleep的唤醒路径上仍有一个独立开关没有被打开。这个开关通常对应唤醒使能寄存器里的某一位，置位后INTP12产生的边沿事件才被允许转成唤醒请求。

/* 允许INTP12作为DeepSleep唤醒源 */ INTP12WUE |= 0x01U; /* 清除之前可能残留的唤醒请求标志 */ INTP12WUF = 0x00U;

我一开始做RH850低功耗时，就遇到过中断配置全对、调试器还能看到边沿标志，但芯片睡死过去的情况。后来发现是INTP12WUE这个唤醒使能位没有置“1”。CS+的代码生成器偶尔会生成这个位，但多数情况下需要你在系统初始化阶段自己补上。特殊要注意：唤醒源使是否能要在进入睡眠点之前写完，且不要写在ISR里，否则第一次能唤醒，第二次睡下去可能就失效了。

这个步骤完成后，可以做一个快速验证：不清除唤醒请求标志，直接进入DeepSleep；如果芯片睡下后立即又被唤醒，说明唤醒路径已经通了，只是标志残留导致误触发。

3.3 第三步：用PMDR序列正确进入DeepSleep

RH850进入DeepSleep需要操作电源管理寄存器PMDR。很多工程师会以为直接给PMDR赋个值睡过去就完了，但在G3MH内核上，SFR写入是流水化的，硬件不会立刻执行模式切换，需要同步指令来保证模式请求生效。

/* 设置PMDR请求bit，请求进入DeepSleep */ PMDR |= 0x01U; /* 流水线同步，确保睡眠请求写入SFR */ __sync(); /* 等待芯片真正完成进入DeepSleep，唤醒后PMDR请求位自动清除 */ while (PMDR & 0x01U) { /* 此时处于DeepSleep状态，等待唤醒事件 */ }

逻辑说明：PMDR的bit0是DeepSleep进入请求。写入之后，硬件进入低功耗状态需要若干个时钟周期，__sync()保证之前的寄存器写操作已经完成。唤醒发生时，硬件清除PMDR的请求位，随后CPU从这条while循环退出继续执行。如果把等待循环写成空指令，也能工作，但代码可读性不好；如果忘掉__sync()或等价操作，可能出现在循环里空转但芯片没有真正进入睡眠的情况。

3.4 第四步：唤醒后的ISR与全局标志设计

INTP12在DeepSleep唤醒后，如果中断使能位处于打开状态，CPU会从睡眠点恢复并紧接着进入INTP12的ISR；若中断未使能，则直接从睡眠点后的指令继续运行。两种方式都合法，我推荐用中断方式进入ISR，在ISR里设置一个全局标志，主循环检测到后统一处理。这比把业务逻辑直接塞进ISR更安全。

volatile uint8_t g_wakeup_flag = 0x00U; void r_intp12_interrupt(void) { /* 清除边沿触发标志，否则下次无法检测 */ INTP12IC = 0x00U; /* 清除唤醒请求标志，防止再次睡下后立即被唤醒 */ INTP12WUF = 0x00U; /* 留下事件标志给主循环 */ g_wakeup_flag = 0x01U; }

这里有个设计细节：不要把I2C读取或CAN发送这类耗时操作放在R_INT_Interrupt函数里面。原因是唤醒后的时钟可能还没完全稳定，外设时钟尚未就绪，急切操作外设反而容易出错。先在ISR里完成标志清理，让主循环在主时钟恢复路径上再做I2C数据采集，是更稳的架构。

4. Wakeup之后：时钟恢复、唤醒源判定与三个排错看点

DeepSleep的难点不只在于怎么睡进去，更在于醒来之后还能正常干活。这一章按唤醒后的处理顺序讲，给出可以直接对照排查的常见问题。

4.1 唤醒第一件事：重新确认并恢复系统时钟

DeepSleep状态下，外部主振荡器通常已经停止（即使没有强制停止，多数工程也会在进入睡眠前主动关掉，以压低待机电流）。唤醒后，芯片会先用内部低速时钟运行，如果此时外设寄存器里的波特率配置依然保留着进入睡眠前的设定，实际通信速率就会不对，导致CAN、UART、I2C都莫名工作异常。

因此唤醒后的第一件事应当是重新建立预期的主时钟源。以使用外部晶振并运行在160MHz的工程为例：

/* 重新使能外部振荡器 */ OSC_EN = 0x01U; /* 等待外部晶振稳定 */ while (OSC_STS == 0U) { /* 循环等待稳定标志位 */ } /* 切换到PLL模式，选择外晶振作为PLL输入源 */ PLL_CTRL = PLL_INPUT_OSC; PLL_CTRL |= PLL_MUL_160;

代码里的OSC_EN、OSC_STS和PLL_CTRL是示意名称，实际工程中对应你所用RH850型号的具体钟控寄存器位。关键点是：不能假设唤醒后PLL还是之前的状态。我在多个项目中发现，代码跑起来后外设寄存器数据没有变化，但通信却乱套，排到最后往往是时钟源还没切回PLL，导致波特率偏差。

4.2 读Flag确认唤醒来源：把INTP12和周期唤醒分开

在实际项目中，DeepSleep的唤醒源经常不止一个。比如同时开了RTC周期唤醒（做定时巡检）和INTP12紧急唤醒（做事件响应），那唤醒发生后就要先判断是谁叫醒的。RH850的唤醒状态寄存器会记录每一个唤醒请求来源，代码里读取并保存原因后再进入业务分支。

uint16_t wakeup_status = READ_WAKEUP_STATUS_REG(); if ((wakeup_status & INTP12_WAKEUP_BIT) != 0U) { /* INTP12外部事件唤醒 */ g_wakeup_cause = WAKEUP_BY_INTP12; } else if ((wakeup_status & RTC_WAKEUP_BIT) != 0U) { /* RTC周期唤醒 */ g_wakeup_cause = WAKEUP_BY_RTC; } else { /* 其他来源或意外复位 */ g_wakeup_cause = WAKEUP_BY_UNKNOWN; }

这段代码展示了一个标准做法：读取唤醒状态寄存器，按位比对，然后把原因存进全局变量。主循环统一读g_wakeup_cause来决策，不会因为多次唤醒而丢失事件背景。如果工程里只有一个INTP12唤醒源，这个步骤可以省略，但保留判断逻辑能让代码抗住后续需求变更。

4.3 三个高频排错案例对照

这三种现场覆盖了绝大多数DeepSleep_Wakeup调试的第一轮问题。排查的时候建议先把CS+的调试器挂在睡眠点前，单步走到PMDR写入，再观察WIN或唤醒状态寄存器；在实际引脚上不施加信号时看是否已经有唤醒请求位被置位，往往能快速定位问题所在。

5. 把DeepSleep_INTP12用进真实业务：带I2C传感器的低功耗巡检

Infinite loop里只跑一个睡眠点太理想化，真实项目里总要在唤醒后干点正事。最后用一个带I2C传感器的低功耗巡检场景，把前面的配置串起来。

5.1 一个I2C唤醒-读取-回床流程

常见做法是把RH850的I2C外设挂一颗环境传感器，平时芯片处于DeepSleep，外部一个物理事件（比如检测电路输出的脉冲）接入INTP12，唤醒后从I2C读取一组数据，处理完再回到睡眠。I2C总线的SCL和SDA在睡眠期间处于静态电平，INTP12则是独立的唤醒信号，两者互不干扰。

void main_loop(void) { system_init(); intp12_wakeup_init(); while (1U) { /* 进入DeepSleep */ enter_deep_sleep(); if (g_wakeup_cause == WAKEUP_BY_INTP12) { /* 唤醒后重新初始化I2C */ i2c_master_init(); /* 读取外部传感器数据 */ uint8_t sensor_data[2]; i2c_read(0x48U, sensor_data, 2U); /* 业务处理 */ process_sensor_data(sensor_data); } /* 清除本次唤醒状态，准备下一次睡眠 */ clear_wakeup_status(); g_wakeup_cause = WAKEUP_NONE; } }

这段代码把进入睡眠和唤醒后处理放在了同一个循环里，结构清晰。注意每次唤醒之后都要重新调用i2c_master_init()，因为I2C外设时钟在DeepSleep下已断，寄存器配置需要恢复。si2c_read的参数里0x48是传感器的七位地址，实际以你的硬件为准。

5.2 用示波器加万用表量出真实功耗

别在CS+调试状态下测量Sleep电流。调试器后台会不断与芯片通信，测量结果会虚高很多。常见做法是把代码烧录到Flash，断开调试器，用精密万用表串联到供电回路，再用示波器电流探头观察唤醒事件瞬间的电流波形。如果测量时发现Sleep电流比手册高出一大截，先从板上的漏电路径查起，比如上拉电阻、LDO静态电流，不一定都是MCU的问题。

5.3 再进一步：双唤醒源让平均电流更低

如果巡检周期是定时的，可以把RTC也配置为唤醒源，让系统按规定时间自己醒来采集数据。INTP12则作为异步事件入口，比如外部一个紧急请求到来，立即唤醒。这种双源设计让DeepSleep不再依赖外部脉冲的节奏。等你把RTC和INTP12两个唤醒源都跑通，再回头调整睡眠时间和唤醒时间，平均电流的优化空间就会清楚很多。

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