1. 课程导论与基础概念

1.1 什么是系统休眠？

系统休眠，说白了就是让系统进入一种低功耗状态。我刚开始接触嵌入式Linux时，觉得这功能挺简单——不就是按一下电源键，屏幕黑了，再按一下亮回来嘛。后来才发现，这里面的门道深着呢。

Linux内核支持几种不同的休眠模式，它们各有各的特点：

模式	内核名称	功耗等级	唤醒延迟	内存状态
Standby	PM_SUSPEND_STANDBY	较低	极短（毫秒级）	保持供电
Suspend-to-RAM (STR)	PM_SUSPEND_MEM	很低	短（几十毫秒）	自刷新
Hibernate	PM_SUSPEND_DISK	接近关机	长（秒级）	写入磁盘

Standby 模式，CPU停掉，但外设基本还活着。我有个项目做智能音箱，用Standby模式做语音唤醒，效果不错，功耗降了30%左右。

Suspend-to-RAM 才是我们常说的"休眠"。CPU断电，内存进入自刷新模式，大部分外设掉电。唤醒时从内存恢复现场。这是嵌入式设备最常用的模式，也是调试的"重灾区"。

Hibernate 模式，把内存内容全部写到磁盘或Flash里，然后整机断电。下次开机时再从磁盘读回来。嗯，这个模式在嵌入式里用得少，因为启动时间本来就短，而且写磁盘那一下也挺耗电的。

1.2 为什么需要调试？

你想想看，一个设备如果休眠后唤不醒，或者唤醒后各种异常，用户会怎么想？我见过一个产品，因为休眠唤醒问题，返修率高达15%。老板急得直跳脚。

常见的调试场景包括：

• 功耗不达标： 休眠后电流比预期高了几十毫安，电池续航直接打八折
• 唤醒失败： 按了按键没反应，只能捅复位孔
• 唤醒后异常： 屏幕花屏、触摸失灵、WiFi连不上
• 休眠/唤醒慢： 用户等得不耐烦，体验极差

我记得有一次调试车载中控，休眠后电流始终降不下来。查了三天，最后发现是一个GPIO没配置成输出低电平，导致外部PMIC一直处于使能状态。就这一行代码的问题。

1.3 常见故障现象概览

做嵌入式Linux这么多年，我遇到的休眠唤醒故障，归纳起来就三大类。咱们一个一个说。

1.3.1 无法唤醒

这是最要命的故障。系统睡下去，就再也醒不过来了。用户只能断电重启。

原因通常有：

• 唤醒源配置错误： GPIO中断没使能，或者中断控制器在休眠时被关了
• 时钟问题： 唤醒需要的时钟源被关闭了
• 电源域问题： 唤醒设备所在的电源域被切断了
• 中断丢失： 唤醒事件来了，但中断被其他设备"吃掉"了

我曾经遇到一个案子，平板电脑休眠后按电源键唤不醒。查到最后，是PMIC的IRQ输出引脚在休眠时被拉低了，SoC根本收不到中断。硬件设计的问题，软件背了锅。

1.3.2 唤醒后死机

系统能唤醒，但起来就崩了。要么直接panic，要么卡在某处不动。

常见原因：

• 内存数据损坏： 休眠期间内存自刷新失败，或者DDR时序不对
• 设备恢复顺序错误： 某个设备依赖另一个设备先恢复，但顺序反了
• 时钟/电压恢复失败： 唤醒后时钟频率不对，或者电压没回到正常值
• DMA问题： 休眠前DMA没停干净，唤醒后乱写内存

1.3.3 外设异常

系统醒了，但某个外设不正常。比如：

• 触摸屏没反应（I2C通信失败）
• WiFi连不上（SDIO接口复位不彻底）
• 音频无声（Codec寄存器丢失）
• 屏幕闪烁（LCD时序没恢复）

这类问题，说白了就是驱动的suspend/resume回调没写好。要么是没保存寄存器状态，要么是恢复顺序不对，要么是复位时序不满足硬件要求。

我有个血的教训：做一款智能门锁，休眠唤醒后指纹识别总失败。查了两周，发现是传感器芯片的初始化序列里有个延时太短，芯片还没准备好就开始发命令了。把那个延时从1ms改成5ms，问题解决。

1.4 知识体系总览

下面这张图，是我自己总结的休眠唤醒调试知识体系。你把它记在心里，后面每章都会用到。

这张图把整个知识体系串起来了。从顶层的三种休眠模式，到底层的调试手段，每一层都有它的作用。后面的课程，我们会一层一层地往下挖。

1.5 本章小结

这一章我们讲了三个核心问题：

• 系统休眠是什么——三种模式各有适用场景
• 为什么要调试——功耗、稳定性、用户体验
• 常见故障有哪些——无法唤醒、唤醒后死机、外设异常

嗯，这些都是基础。但基础不牢，后面调起来会很痛苦。我见过太多人，一上来就对着代码改，改完发现还是不行，最后连问题出在软件还是硬件都搞不清楚。

所以，把这一章的内容消化掉，后面的路就好走了。