0.前言

技术和经历经验都有限，以下内容仅供初学者参考和个人总结记录，不定期更新。

都是使能协议栈开启BLE广播的情况

协议栈：s132_nrf52_6.1.1

SDK：nRF5_SDK_15.3.0_59ac345

1.进入低功耗方式

nRF52832进入低功耗或保持低功耗方式比较简单，关闭所有能唤醒的定时器中断（包括但不限于：协议栈模拟定时器app_timer、各种软硬件定时器、RTC）。

注意是唤醒进入定时服务函数的动作要关闭，有的定时器本身可以不关闭（例如RTC，PS：app_timer也是RTC实现的），具体的可以测试。

然后执行下面的函数，仿真打断点发现进入此函数后不再出来，进入低功耗成功。此时功耗最低点可以下降到<30uA。

/**@brief Function for handling the idle state (main loop).** @details If there is no pending log operation, then sleep until next the next event occurs.*/
void idle_state_handle(void)
{nrf_pwr_mgmt_run();
}

硬件上IO口的拉高低问题，所有MCU都差不多，不赘述。

2.如果可能，打开DCDC功能

需要硬件支持，芯片的46、47脚接电感，具体参考手册。

3.有些用到DMA的外设进入低功耗前必须关闭，否则会不断唤醒，功耗激增

比如UART，只要使能（NRF_UART0->ENABLE = 1），就会无法进入休眠，一定要关闭。否则将会导致第1条中的进入低功耗失败。

4.GPIO设置为输入可能并不是最省电的方式

某些情况下，直接输出高或低比设置为输入更省电。

5.硬件SPI可能会与协议栈冲突，导致功耗增加

硬件SPI简单的关闭失能后，还是会导致功耗增高，关闭协议栈后正常，原因未知，正确关闭方法暂时未知，只能暂时使用模拟SPI。

评论区朋友反馈，这可能是 GPIOTE与TWI（SPI）冲突造成，可以尝试如下方式解决

6.看门狗的坑：可能偷偷复位系统

该芯片看门狗比较特别，开启后就无法软件关闭，此外，在休眠期间协议栈会唤醒CPU导致看门狗会偷偷计数而用户代码完全不知道，如果只是单纯一直休眠而不定期唤醒喂狗，可能会导致系统不久后自动复位。

7.FPU的问题

此问题听说过还没遇到过，可以参看

8.外部中断的选择

外部中断分为port event（GPIO Sense）和GPIOET，两者功耗可能不一样（前者是低功耗，实测2uA；或者是高功耗，实测9uA）

但是port event的使用局限性比较大，比如：一个IO口进入中断后，除非再解除，否则其他IO口无法检测、只能检测高电平或低电平，且速度不能太快，等

详见：

9.待续。