430低功耗单片机如何设置系统以最低功耗运行，MSP430案例分享|产品概述|上海羊羽卓进出口贸易有限公司

如何设置系统以最低功耗运行，MSP430案例分享

MSP430系列单片机的各个模块都可以独立运行，如定时器、输入/输出端口、A/D转换、看门狗、液晶显示器等都可以在CPU休眠的状态下独立工作。若需要主CPU工作，任何一个模块都可以通过中断唤醒CPU，从而使系统以最低功耗运行。

让CPU工作于突发状态可以充分利用CPU的低功耗性能。通常，使用软件将CPU设定到某一低功耗模式，在需要时使用中断将CPU从休眠状态中唤醒，完成工作后又可以进入相应的休眠状态。如：让CPU工作在LPM3状态，通过中断事件转换到AM活动模式，根据运行需要，又可以从AM状态进入相应的低功耗模式：LPM0/LPM3或LPM4。

系统的这些低功耗特性是靠系统对中断的响应来实现的。系统响应中断的过程：

硬件自动中断服务。包括PC入栈、SR入栈;中断向量赋给PC;GIE、 CPUOFF、OSCOFF和SCG1清除;以及IFG标志位清除（单源中断标志）

执行中断处理子程序。

执行RETI指令（中断返回），包括SR出栈;PC出栈。

例如：系统初始化完成后工作于低功耗模式0，中断事件触发到活动模式，中断处理结束后进入低功耗模式3。

;主程序

……;初始化操作开始

……;

……;初始化结束

BIS #GIE+CPUOFF， SR ; 主程序中设置低功耗模式0，LPM0

;……;程序在这里停止

;中断子程序

……

……; 中断处理结束

BIS #GIE+CPUOFF+SCG1+SCG0， 0（SP） ; 设置SR为低功耗模式3，LPM3

RETI; 中断返回

;系统进入低功耗模式3

……

如果主程序期待在中断返回之后继续执行某些操作，可以在中断处理子程序中改变SR的值为AM模式，系统中断退出后根据恢复的SR和PC的值，来执行设定的某些操作。

L1 操作1

L2 操作2

…… ;中断处理开始

BIS #GIE+CPUOFF， 0（SP） ; 设置SR为活动模式，AM

RETI; 中断返回，系统进入活动模式

……

主程序执行到LPM0处停止执行，L1，L2等语句不执行。之后中断事件保存PC（L1指令地址）和SR（低功耗模式0），中断唤醒CPU，执行中断处理程序;由于在中断处理子程序中将SR设置为活动模式，所以中断返回后CPU处于活动状态，并从PC指向的L1指令处开始继续执行……

十年硬件老司机，结合实际案例，带你探索单片机低功耗设计

经过了多年的低功耗硬件设计 （公司硬件设计和软件设计是分开的，我一直是做硬件，在面对低功耗生产事故中做硬件的往往很苦逼），其中容易出的一个问题是单片机进睡眠模式前IO没配好 ，产品上主要出的问题是这些出问题的IO比较隐蔽，当时经过多次测试也没测试出来，后来在生产或现场才发现的概率性功耗偏大 的问题。

站在硬件的角度，最近才意识到原来软件上一直容易犯的一个毛病是进睡眠前没有把所有IO重新配置一遍 ，这样容易导致IO低功耗的BUG出现。

这个心得总结起来是：要求在进睡眠模式前把所用的单片机的所有的IO从代码上1个IO接1个IO的配置一遍。不要偷懒，不要多个IO一起配置。

分析：

外设时钟

外设的时钟没关，单片机内部模块没关等，部分单片机进睡眠后自动会关闭，部分不会自动关闭的，没关的话当场测试功耗就偏高，会马上发现的。所以这些在实际生产中都没出过问题。

IO配置

1个IO接1个IO配置，不要多个IO用类似BIT1|BIT2……，|=0xxx这类一起配置。因为代码上越是直观，出现笔误的概率越低。 而且我们核对IO的时候都是一个IO一个IO的去核对配置对不对。所以代码上依次写一下其实花了不了多少时间和代码空间的。花个5到30分钟撑死，但是后续节省的时间和金钱就不好说了。人的总是有惰性的，我自己写代码的时候之前进低功耗前也只是配置了一部分，现在慢慢开始习惯全部配置 ，很多配置可以复制之前的IO初始化（这个已经养成了1个IO，1个IO的配置，改起来其实很舒服的）。

案例分析

实际出现的最麻烦，最隐蔽的情况往往跟IO的配置有关，越简单的往往越容易出问题。

1、比如大多数情况下程序从A子程序进入睡眠后IO配置没问题，经过大量测试也没发现问题。但是当某次执行了B后再进睡眠，B中对IO进行了操作，再进睡眠没有把IO改回来 ，这时问题就可能出现了。而要是执行C,D……等程序再睡眠都不会出IO的隐患。

案例： 产品在客户那里发现有50%左右放了一段时间后电池耗光。研发 百思不得其姐 ，多次查看代码没发现问题，之前也没出现死机的问题（死机后会导致不能进低功耗，功耗超高）。派人去现场测试，进过大量测试后发现一个IO部分产品输出高。导致电流多了1mA左右。原因是客户上电做了秒脉冲输出，下电后产品就用电池供电了。客户下电前没有配置关闭秒脉冲输出，程序下电后也没有把IO配置回来， 导致有50%的概率IO输出高电平。

2、一个产品已经生产了几万台，一直没发现问题。后来换了一家PCB厂家后，生产发现功耗个别产品偏高个10uA左右， 研发拿回来分析，发现换了芯片就好了。但是生产出现百分之几的功耗不好的情况，芯片不可能出现这么大概率的损坏。430芯片，走正规供应商的。再一个IO一个IO的查找，通过手摸IO最终发现一个连光耦输入端的IO配置的是输入模式。换了芯片好了是因为焊接过，板子变脏，电阻变小，IO有一个比较固定的偏向与GND的电压，因而没问题。之前没问题可能是板子的阻值比现在的这家小了点，或当时生产的时候湿度大点，或光耦的反向漏电流大些，也是各种可能了。软件发现这个IO本来是配置没问题的，中间不知道哪里配置过或配置别的IO时不小心连这个IO也配置了。总之当时没搜到这个IO的配置哪里改动了，只是在进低功耗前重新配置了下这个IO。

3、产品上使用的一个外购低功耗RF模块的IO问题。使用CC1101和430F2132。都算低功耗的芯片吧。前后找了2家开发模块，第一家2132一个IO没配置好，生产阶段发现部分产品功耗偏高。后来是因为领导的原因换了家做无线的厂家来做这个，还是CC1101+2132方案。照理来说之前犯过错误应该吸取经验教训了吧。并且软件人员也是老手了。结果生产是没问题，发货到客户那里还是发现了个别产品出问题， 最后还是发现一个IO没配置好状态。

4、以上心得很简单，但是是付出多次时间+金钱得出的惨痛心得。 而且这些都是软件的问题，但是功耗问题往往第一个找个是硬件：你设计的产品功耗偏高，电池没电，你查查看，哪里出问题了。 做硬件的又开不到代码，软件人员往往开始还不承认IO配置上有问题，尤其是之前找外面厂家开发的模块，他们的意思是，我做软件xx年了。开发了这么多产品，这么简单的一个产品怎么会出问题 ，是你们自己的产品没做好才出的问题。苦逼的硬件工程师没办法，只能自己想各种办法找到出问题的那个IO。软件人员经过改代码对比测试才完成，但是软件最后还是不会说自己的代码有问题。

5、关于IO的问题。430单片机IO设置是最弱的 ，大部分没有上下拉电阻，默认是输入状态，没配置IO就容易出功耗问题，ST的相对好的多，51的IO默认的51状态有上拉电阻，没用到的脚不去配置也不会出问题。空的IO我之前喜欢配置成输出0状态，最近在用STM8S看了下代码发现喜欢配置成上拉输入状态，STM8S没下拉电阻，STM32有，配置成下拉输入状态更好些，不小心碰到不会对外输出电流。题外话： 关于单片机的低功耗模式之前没深入了解STM32，最近才发现进最低功耗的STANDBAY模式RAM中数据对丢失，这点不如8位机，之前用STC的51和STM8系列从不担心ram数据丢失的问题。看STM32L系列进最低功耗也有这个问题，只是可以掉电保的RAM区域分的更多，更大。