新手教程：TI SDK电源模块配置入门-平芜编程栈

从零开始：TI SDK电源配置实战指南

你有没有遇到过这样的情况？板子通电后，串口毫无动静，调试器连不上，翻遍手册也找不到头绪——最后发现，只是某个外设的电源域没打开。这在TI的多核处理器开发中太常见了。尤其是AM62x、AM64x这类复杂SoC，芯片内部有十几个电源域，稍不注意就会掉进“黑盒上电”的坑里。

别担心，这篇教程就是为你准备的。我们不讲空泛理论，也不堆砌术语，而是带你一步步搞懂：为什么系统启动依赖电源配置？怎么用TI SDK安全、高效地完成这件事？以及最常见的“卡死”问题到底出在哪？

一、先搞明白：你的CPU其实是个“分段供电”的拼图

想象一下，一块像AM62x这样的SoC，并不是整体一起得电工作的。它被划分为多个独立的“供电区域”，也就是所谓的电源域（Power Domain）。每个域可以单独开启或关闭，就像家里的不同房间可以分别开灯关灯一样。

常见的几个关键电源域包括：

WKUP_PD：唤醒域，哪怕系统休眠也常驻供电，里面放着RTC、低功耗GPIO这些“守夜人”；
MPU_PD：主处理单元域，跑Linux的Cortex-A核心就在这里；
MCU_PD：微控制器域，通常是Cortex-M或R5F核心负责实时任务；
PER_PD：外设域，UART、SPI、I2C等都归它管。

🔍重点来了：如果PER_PD没上电，就算你在代码里初始化了UART驱动，也不会有任何输出！因为硬件根本没通电。

所以，电源配置的本质，就是告诉芯片：“哪些区域要先上电？顺序是什么？什么时候能切到低功耗？”

二、别再手撸寄存器了：TI SDK是怎么帮你“省事”的？

过去做嵌入式开发，工程师得一页页翻《Technical Reference Manual》(TRM)，手动计算PSC寄存器偏移地址，写一堆*(volatile uint32_t*)0x43000100 = 0x3这种代码。不仅容易出错，还难移植。

现在，TI SDK通过一套分层设计，把这一切封装了起来：

应用层（你写的代码） ↓ PMF / Power Driver API（如 Power_setTransition()） ↓ 底层驱动（psc.c，对接硬件PSC控制器） ↓ 硬件（SoC上的Power and Sleep Controller）

最上面一层，你可以只调一个函数，比如：

Power_setTransition(Power_DOMAIN_PER, Power_ACTIVE);

下面的事——检查依赖、发命令、等时序、轮询状态——全由驱动自动完成。是不是轻松多了？

而且，TI还提供了图形化工具SysConfig，直接拖拖拽拽就能完成配置，生成标准C代码和设备树节点。这对新手来说简直是救命稻草。

三、核心武器：PSC控制器到底干了啥？

PSC（Power and Sleep Controller）是整个电源管理的“执行中枢”。你可以把它理解为一个带交通信号灯的调度中心，控制着各个模块的上电顺序。

它是怎么工作的？

每个电源域（PD）和模块域（MD）都有对应的控制寄存器。典型流程如下：

软件向某个模块的MDCTL寄存器写入目标状态（比如ENABLE）；
PSC判断该模块所属的电源域是否已激活；
如果父域没开，PSC会先去申请开启电源域；
等电压稳定后，设置完成标志，模块才能真正工作。

举个例子：你想用SPI Flash，但它的电源来自PER_PD。如果PER_PD没开，即使SPI模块本身的使能位写了1，也没用。

关键寄存器一览

寄存器	作用说明
`MDCTL[n]`	第n个模块的控制寄存器，决定其期望状态
`PTSTAT`	只读状态寄存器，哪一位为1，表示对应域已就绪
`PDSTAT[m]`	第m个电源域的状态，ACTIVE还是SLEEP

⚠️ 实际开发中，你不一定要直接操作这些寄存器。但当你调试失败时，用JTAG读一下PTSTAT，往往能一眼看出哪个域卡住了。

四、实战演示：用SysConfig搞定电源策略

我们以AM62x平台为例，假设需求是：让系统支持待机模式下通过GPIO快速唤醒，并保持SPI Flash供电不断。

步骤1：打开SysConfig

在CCS项目中双击.syscfg文件即可进入图形界面。

步骤2：配置电源拓扑

进入Power Configuration页面，你会看到一棵清晰的电源树：

- WKUP Power Domain ├── RTC └── GPIO_INT (勾选: Wake-up Source) - MCU Power Domain - MPU Power Domain - PER Power Domain └── SPI1 (勾选: Retain Power in Low Power Mode)

同时，在WKUP域设置“Always On”，确保低功耗时不掉电。

步骤3：设置唤醒源

切换到Low-Power Behavior标签页，选择允许从GPIO或RTC唤醒系统。SysConfig会自动生成相应的中断使能代码。

步骤4：导出并编译

点击“Generate Sources”，工具会输出：
-power_cfg.c：包含默认电源策略
-power_policy.c：低功耗行为定义
- 设备树片段（用于Linux）

烧录后，系统就能实现毫秒级唤醒，且SPI数据不丢失。

✅小贴士：第一次调试建议先生成“全域能用”的配置，确认基本功能正常后再逐步裁剪，避免因缺电导致外设异常。

五、那些年我们都踩过的坑：常见问题与解法

❌ 问题1：上电后串口没输出，JTAG也连不上

可能原因：PER_PD或WKUP_PD没有正确使能。

排查方法：
1. 检查power_cfg.c中是否有对Power_DOMAIN_PER的使能调用；
2. 使用XDS调试器连接，查看PSC.PTSTAT寄存器值；
3. 若PTSTAT[PER] == 0，说明外设域未就绪；
4. 进一步检查启动流程是否执行了power_init()函数。

有时候，U-Boot阶段忘了调用电源初始化API，Kernel根本拿不到控制权。

❌ 问题2：系统进入睡眠后无法唤醒

真相往往是：你以为设置了GPIO唤醒，但实际上电源策略把它给“断电”了。

解决方案：
- 在SysConfig中明确将该GPIO所在的电源域设为“Retained”或“Always-On”；
- 确保中断控制器本身没有被关闭；
- 查看生成的power_policy.c中是否注册了正确的唤醒源回调函数。

💡 经验之谈：可以用示波器测量相关电源轨电压，看看睡眠时是否真的降到了0V。如果是，那肯定醒不过来。

❌ 问题3：动态切换DVFS时报错，提示电源不稳定

根本原因：电压调整需要时间，而你的代码没等够。

应对策略：
- 在调用Power_setVdd()前后加入适当延时（如usleep(100)）；
- 检查外部PMIC（如TPS6594）的响应速度是否达标；
- 启用Power_logInfo()日志功能，观察状态转换全过程。

有些情况下，还需要在设备树中配置regulator的ramp-delay参数，告诉内核“我这个电源爬升慢一点”。

六、最佳实践清单：老司机的经验都在这儿了

按依赖顺序上电
永远记住：父域 → 子域。先开WKUP_PD，再启MPU_PD，最后激活外设。
启用运行时日志
在调试阶段打开Power_enableLogging()，每一笔状态变更都会打印出来，极大提升排错效率。
不要忽略约束机制
使用Power_setConstraint(Power_DISALLOW_SLEEP)防止关键操作被打断。例如固件升级时，绝不能让系统突然休眠。
留一份“安全配置”
做一个所有电源域全开的.syscfg备份，当新配置出问题时，快速回退验证。
结合硬件实测
工具再智能也不能代替实测。用示波器抓取VDD_CORE的上电曲线，确认斜率和延迟符合JEDEC规范。
低功耗设计要“反向思考”
不是“我要开什么”，而是“我能关什么”。每关闭一个非必要电源域，静态功耗就能下降几毫安。