T32Pro-AOV 唤醒后音频驱动加载卡死及无法取流的排查与修复

适用范围

        本文适用于 T32 平台使用 AOV 低功耗模式的音频场景。系统冷启动后首次加载音频驱动正常，但卸载驱动、进入 AOV、完成唤醒并再次加载音频驱动时，如果出现加载过程卡死、AIC 寄存器状态异常，或者驱动能够加载但录音、放音无法取得音频流，可以按照本文思路检查 AIC 时钟、PDMA 恢复以及 clk 引用计数。

问题现象

        系统上电后，音频驱动可以正常加载，录音或放音链路也能够工作。卸载音频驱动并进入 AOV 后，系统虽然能够唤醒，但再次加载音频驱动时可能卡住，同时读取到的 AIC 寄存器状态异常。完成部分时钟逻辑修正后，驱动加载可以恢复，但音频数据仍可能无法传输，表现为录音或放音无法取流。

        该问题在程序运行、UART0 与外部 MCU 相连且处于下拉状态时可以触发，而 UART0 两个引脚悬空时音频工作正常。不运行程序且不进行音频出流时，即使 UART0 处于下拉状态，休眠唤醒后的音频也可以正常工作。UART0 的连接状态可用于构造对照环境，但最终需要修复的是音频时钟恢复、PDMA 恢复和 clk 引用计数逻辑。

诊断过程

        排查此类问题时，首先应比较冷启动首次加载与 AOV 唤醒后再次加载的差异。首次加载正常而唤醒后加载异常，说明常规初始化流程基本可用，检查重点应转向低功耗期间丢失的硬件状态以及唤醒后的恢复流程。

        第一步检查 AIC 时钟。AOV 休眠期间，实际 CPM 寄存器会被清零，但内存中的 clk->source->rate 仍保留休眠前的值。唤醒后执行 clk_set_rate 时，如果代码只比较目标频率与缓存频率，就会因为两者相同而直接返回。此时软件记录看似正确，硬件时钟实际上却没有重新配置，因此会出现 AIC 时钟异常、寄存器状态异常以及驱动加载卡死。

        第二步检查音频传输通道。AIC 时钟恢复后，如果驱动可以加载但仍然无法取流，应继续检查 PDMA 是否已经随系统唤醒而恢复。音频数据传输依赖 PDMA，仅恢复 AIC 时钟不能使整个音频链路重新工作。

        第三步检查 clk 引用计数。应沿驱动加载、录音、放音和卸载路径核对时钟使能与关闭操作。录音或放音路径重复使能对应 clk 时，count 会额外增加一次。驱动卸载后，如果 count 仍为 1，下一次加载检测到非零计数便会直接返回，不再执行真正的硬件时钟使能。

根因

        该问题由三处软件逻辑共同造成。首先，AOV 休眠清除了 CPM 寄存器状态，但内存仍保留旧的 clk->source->rate，导致唤醒后的 clk_set_rate 错误跳过 AIC 时钟重配。其次，唤醒流程没有恢复音频传输依赖的 PDMA，导致控制器时钟恢复后仍然无法传输音频数据。最后，录音或放音路径重复使能 clk，使引用计数与真实硬件状态不一致，驱动再次加载时因此跳过硬件时钟使能。

分步修复

    1. 修正 AIC 时钟重配逻辑

        调整 AOV 唤醒后的时钟恢复逻辑。只要低功耗过程已经使 CPM 寄存器状态丢失，就不能仅依据内存中保存的 clk->source->rate 判断硬件已经处于目标频率。即使缓存频率与目标频率相同，也需要重新完成 AIC 时钟配置，使软件记录与硬件状态重新一致。

    2. 在唤醒流程中恢复 PDMA

        将音频传输依赖的 PDMA 纳入 AOV 唤醒恢复流程。AIC 时钟恢复负责重新建立音频控制器的工作条件，PDMA 恢复负责重新建立音频数据传输通道。两部分都正确恢复后，录音和放音链路才能正常取流。

    3. 移除重复的 clk 使能

        梳理音频驱动加载、录音、放音和卸载过程中的时钟生命周期，移除录音或放音路径中多余的 clk 使能操作，并确保每次有效使能都有对应的关闭操作。这样可以避免卸载驱动后残留 count=1，使下次加载能够执行真实的硬件时钟使能。

验证结果与方法

        完成三处修复后，AOV 唤醒后再次加载音频驱动时的卡死和 AIC 时钟异常得到解决，PDMA 恢复后音频无法取流的问题得到解决，移除重复 clk 使能后，驱动卸载再加载时也能够正常使能硬件时钟。

        建议按照完整的状态转换顺序验证。先在上电状态加载音频驱动并确认录音或放音正常，再卸载驱动、进入 AOV、执行唤醒并重新加载驱动，观察加载过程能否完成以及 AIC 状态是否正常。随后执行录音或放音，确认音频流能够通过恢复后的 PDMA 正常传输。最后再次执行卸载和加载，检查 clk 引用计数是否随使能与关闭正确变化，并确认再次加载时不会跳过硬件时钟使能。还可以分别使用 UART0 连接并下拉、UART0 引脚悬空两种条件进行对照，以覆盖原有触发场景。

实践注意事项

• 低功耗过程可能使硬件寄存器状态丢失，而内存中的软件缓存仍保留旧值。唤醒恢复不能只依赖缓存值判断硬件是否已经完成配置。

• 驱动能够完成加载并不代表音频链路已经全部恢复。AIC 时钟与 PDMA 承担不同职责，应结合实际录音或放音检查数据传输。

• 修改 clk 逻辑时，建议同时检查加载、录音、放音、卸载和唤醒恢复路径，确保引用计数与真实硬件开关状态一致。

• UART0 的连接与下拉状态可以作为复现对照条件，但不应替代对 AIC 时钟恢复、PDMA 恢复和 clk 引用计数的检查。

• 对其他低功耗外设问题，也建议同时核对软件缓存、硬件寄存器、依赖模块和引用计数，避免只恢复单一模块后遗漏完整数据链路。