4. 时钟与复位子系统：PLL配置、时钟树分析、复位源定位、驱动调试实例

时钟和复位，是嵌入式系统的“心跳”与“命门”。

在 Jacinto 平台上，我见过太多因为时钟配错一个分频系数，或者复位源没找对，导致整块板子“死得不明不白”的案例。说实话，这章的内容，就是帮你练就一双火眼金睛，能快速定位这类问题。

4.1 PLL配置：从数据手册到寄存器

PLL 配置，说白了就是算数。但算错了，板子就不干活。

我个人习惯，拿到一个新平台，第一件事就是看 Clock Tree 文档。Jacinto 的 PLL 通常包含以下几个关键参数：

参数 说明 常见坑点
REFCLK 输入参考时钟 必须与晶振或外部时钟源匹配
PLL_MULT 倍频系数 注意范围，超出会导致失锁
PLL_DIV 分频系数 输出频率 = (REFCLK * MULT) / DIV
LOCK_TIME 锁定时间 配置后必须等待，不能立即操作外设

核心公式：

Fout = (Fref * N) / M

其中 N 为倍频系数，M 为分频系数。记住，这个公式是死的，但芯片的 PLL 状态机是活的。

我曾经在一个项目中，因为忽略了 PLL 的 Bypass 模式，导致配置完成后，时钟源还是走的旁路。现象就是：寄存器读出来都是对的，但外设就是跑不起来。折腾了两天，最后用示波器一量，才发现时钟频率根本没变。

4.1.1 配置流程

标准的 PLL 配置流程，我建议你按这个步骤来：

  1. 读当前状态：先检查 PLL 是否已经锁定，避免重复配置。
  2. 进入 Bypass 模式：切换时钟源到旁路，防止配置过程中输出不稳定。
  3. 写倍频/分频寄存器：一次性写入，或者按顺序写入，看芯片要求。
  4. 等待锁定：轮询状态寄存器，或者直接延时（保守做法）。
  5. 切换回 PLL 模式：确认锁定后，切回 PLL 输出。
  6. 验证输出：通过 Timer 或 PWM 模块测量实际频率。

注意： 有些 Jacinto 系列的 PLL 有 Fractional-N 模式。如果你不需要小数分频，千万别乱开。我见过有人开了 Fractional 模式，结果引入了大量抖动，导致以太网 PHY 无法同步。

4.2 时钟树分析：谁是谁的爹

时钟树，就是一张“认祖归宗”的图。你得搞清楚，哪个模块的时钟是从哪个 PLL 分出来的。

Jacinto 的时钟树通常很复杂，有多个 PLL（如 MPU_PLL、DDR_PLL、PER_PLL、GPU_PLL 等）。每个 PLL 下面又挂着一堆分频器和门控。

我一般会画一张简化的时钟树关系图，方便自己排查问题。比如下面这张：

Jacinto 简化时钟树关系图 Jacinto 简化时钟树关系图 外部晶振 (REFCLK) MPU_PLL DDR_PLL PER_PLL A53 集群 DDR 控制器 L3/L4 总线 外设 (UART/I2C) 以太网 排查思路 外设不工作 → 查其时钟源 → 追溯至父 PLL → 检查 PLL 锁定状态 → 检查分频器配置

你看，这张图里，DDR_PLL 不仅给 DDR 控制器用，还可能给 L3/L4 总线提供时钟。如果 DDR 频率配错了，总线也会跟着遭殃。这就是为什么有时候你改了一个外设的时钟，结果整个系统都崩了。

我的小技巧： 在调试时，我会在驱动初始化阶段，把关键时钟的 频率值 打印出来。比如：

printk("MPU PLL: %lu Hz\n", clk_get_rate(clk_get(NULL, "mpu_pll_clk")));
printk("DDR PLL: %lu Hz\n", clk_get_rate(clk_get(NULL, "ddr_pll_clk")));

这样一眼就能看出时钟树有没有断掉。

4.3 复位源定位：谁动了我的系统

系统无缘无故重启了？别慌，先查复位源。

Jacinto 的复位源有很多种：上电复位、看门狗复位、软件复位、外部引脚复位、热复位等等。每个复位源都会在 PRCM (Power, Reset, Clock Management) 模块的寄存器里留下痕迹。

我遇到过最经典的一个案例：客户反馈设备在高温环境下会频繁重启。我一开始怀疑是电源问题，后来通过读取复位状态寄存器，发现复位源是 WDT (看门狗)。再一查，发现是某个外设在高温下响应变慢，导致喂狗线程超时。你看，定位到复位源，问题就解决了一半。

4.3.1 复位源寄存器读取示例

在 Jacinto 平台上，通常可以通过读取 PRCM_RSTST 寄存器来获取复位源。下面是一个简单的读取函数：

#include <linux/io.h>
#include <linux/kernel.h>

#define PRCM_BASE        0x4A300000
#define PRCM_RSTST       0x0014

void check_reset_source(void)
{
    void __iomem *prcm_base;
    u32 rst_st;

    prcm_base = ioremap(PRCM_BASE, SZ_4K);
    if (!prcm_base) {
        pr_err("Failed to map PRCM registers\n");
        return;
    }

    rst_st = readl(prcm_base + PRCM_RSTST);
    pr_info("Reset Status Register: 0x%08x\n", rst_st);

    if (rst_st & BIT(0))
        pr_info("Reset source: Power-on Reset (POR)\n");
    if (rst_st & BIT(1))
        pr_info("Reset source: External Reset (EXT)\n");
    if (rst_st & BIT(2))
        pr_info("Reset source: Watchdog Reset (WDT)\n");
    if (rst_st & BIT(3))
        pr_info("Reset source: Software Reset (SW)\n");

    iounmap(prcm_base);
}

注意： 这个寄存器通常是 粘性 (sticky) 的，也就是说，复位源标志位会一直保持，直到你手动清除。所以，在系统启动早期读取它，才能拿到最准确的信息。如果等到内核完全启动后再读，可能已经被其他代码清掉了。

4.4 驱动调试实例：一次真实的PLL失锁排查

好了，理论讲完了，咱们来看一个真实的调试案例。

有一次，我在调试 Jacinto 平台的 VPIF (视频输入) 驱动。现象是：摄像头采集的图像偶尔会出现撕裂，而且频率不固定。

排查过程：

  1. 怀疑是 DMA 问题：检查了 DMA 描述符，没问题。
  2. 怀疑是中断延迟：用 ftrace 看了中断响应时间，正常。
  3. 最后回到时钟：用示波器量了 VPIF 的像素时钟，发现频率在抖动！

我立刻去查 VPIF 的时钟源。发现它来自 PER_PLL 的一个分频输出。然后我读取了 PER_PLL 的状态寄存器，发现 LOCK 位 在周期性清零！这说明 PLL 在反复失锁。

为什么会这样？我仔细看了数据手册，发现 PER_PLL 的供电电压有一个 纹波要求。我让硬件同事去量了供电纹波，结果发现纹波超标了 30%。

根因： 电源纹波过大 → PLL 内部电荷泵工作不稳定 → 周期性失锁 → 输出时钟抖动 → 视频采集撕裂。

解决方案： 在 PER_PLL 的供电引脚附近增加了一颗 10uF 的陶瓷电容，问题解决。

这个案例告诉我们：时钟问题，有时候不一定是软件配错了，也可能是硬件环境不达标。 作为 BSP 工程师，你得有这种“软硬通吃”的意识。

4.5 本章小结

时钟与复位，是 Jacinto 平台的基石。配置 PLL 时，要算好倍频分频，别忘了等待锁定。分析时钟树时，要理清层级关系，知道谁依赖谁。定位复位源时，要第一时间读取粘性寄存器。

嗯，这章的内容就到这里。记住，遇到诡异的问题，先查时钟，再查复位。这两步走对了，后面就顺了。

← 上一章 📖 返回目录 下一章 →