瑞萨 RH850 F1K SubOSC 晶振无法启动问题分析与解决

本文针对瑞萨 RH850 F1K/R7F7015873AFP-C 芯片在实际应用中出现的 SubOSC 晶振无法启动问题，详细介绍了其现象、分析过程与解决方案。其中所述的现象和错误具有普遍性，对深入理解 RH850 F1K 的 Sub Oscillator (SubOSC) 模块工作原理及规避类似设计问题具有参考价值，可供工程师或相关技术人员提供参考和借鉴。

RH850/F1K 是瑞萨 RH850/F1x 系列中的一组单芯片微控制器，专为汽车电气车身应用而设计。R7F7015873AFP-C 是 F1K 系列中极具性价比的一个典型型号，它支持 120Mhz CPU 频率（瑞萨私有内核 G3KH），2MB Code Flash+64KB Data Flash，128KB Local RAM+64KB Retention RAM, 同时支持 ASIL-B 功能安全等级，关键是提供 AUTOSAR MCAL，以满足目标用户对 AUTOSAR 架构应用的需求。

本文基于实际案例，逐步介绍问题背景、现象、分析过程、解决方案及总结。阅读本文需要读者对 AUTOSAR、时钟、软硬件具备基本的概念。

在已量产的产品上，有两块设备偶发出现 RTC 功能失效。

因为 RTC（Real-Time Clock）是为嵌入式设备提供精确时间戳的实时时钟，是设备系统的时间参考。日常年/月/日/时/分/秒计数、以及网络报文的时间戳都依赖 RTC 来设定。

一般即使系统处于低功耗休眠状态，RTC 都在运行。RTC 失效后，设备系统无法计时，与此有关的功能模块都出现与时间相关的错误。在汽车电子产品中，该问题将使设备变得不可靠，甚至将系统置于危险之中，属于不可接受的错误。

经过排查发现， 32.768Khz 的晶振没有起振。

使用的振荡器和外部谐振电路都按照石英晶体厂家的参考设计来搭建，经查，所用的晶振已和 R7F7015873AFP-C 做过匹配，R478 的阻值、C33 和 C34 的容值都是按照该型号的推荐使用，电路设计上看似乎没有问题。

因为 SubOSC 外部电路比较简单，不涉及高速信号问题，PCB 走线在 FC-13A 的设计指导中没有特别要求，经确认 PCB 走线也没问题。下一步就是排查是否器件失效，于是做了 32.768Khz 晶振和外围 C33、C34 电容甚至 R478 电阻的替换，结果仍然量不到时钟信号。于是开始考虑是否软件问题导致。

R7F7015873AFP-C 的 XT2 PIN 脚和 IP0_0 共用，可以复用为一个 input pin。但是在此情况下，SOSC（SubOSC 模块）的 SOSCE 寄存器和 IPIBC 寄存器要做对应设置，具体来说是停掉 SOSC 功能，并且设置 IPIBC0_0 位为 1。

检查项目代码中最终 SOSCE — SubOSC Enable Register 寄存器和 IPIBCn 寄存器的设置结果，是符合上述逻辑的。

进一步对比项目中原有代码与 Smart Configurator 生成的默认初始化代码。RTC 驱动部分有 AUTOSAR 架构的，通过符合 AUTOSAR 标准的第三方配置工具生成；也有非 AUTOSAR 架构的，主要是项目工程师自己手写。SubOSC 初始化代码主要通过瑞萨配置工具 Smart Configurator 生成（后来发现项目工程师为了适配 AUTOSAR 架构驱动代码，或者为了特定优化目的，也有手动修改 SubOSC 初始化代码的记录）。

RTCA 的驱动代码主要在 r_cg_rtca.c，r_rg_rtca.h，r_cg_rtca_user.c 几个文件中，经对比，项目方代码主要差别在于中断处理这部分，非 AutoSAR 代码是有以下这部分中断相关处理，这部分初步分析可能和项目的 AUTOSAR 架构 RTC 上层应用设计相关，属于正常情况。

下图（图7）为代码对比，右边为 Smart Configurator 生成的默认 RTCA 驱动代码，左边为项目非 AUTOSAR 机构的 RTCA 驱动代码，也是中断处理部分有差异，但是该中断处理的差异，可以看作针对项目的 RTC 应用而做的调整，是可以理解的。

在对比项目不同驱动和初始化代码的同时，做了软件方面的交叉验证。因为项目存在 AUTOSAR 和非 AUTOSAR 的不同软件版本，为了进一步定位是软件原因？硬件原因？还是 MCU 失效？在故障设备上做了软件版本的交叉升级测试，发现以下现象：

重烧写 FLASH 到某一软件版本（经确认是 AUTOSAR 工具生成的底层驱动），32.768Khz 的时钟信号恢复；再把 FLASH 烧写回到某一软件版本（经确认是非 AUTOSAR 架构的手写底层驱动），32.768Khz 的时钟信号又消失。

至此定位为软件问题，不考虑 MCU 失效。但是因为项目工程中夹杂 AUTOSAR 工具生成的代码、Smart Configurator 生成的代码和手写优化调整代码，所以仍然不知道是哪部分出的问题。

这部分代码主要是 r_cg_cgc.c 和 r_cg_cgc.h，发现 SubOSC 的初始化代码有较大差异，下图（图8）为项目 SubOSC 初始化代码与工具生成默认代码对比，其中右侧为 Smart Configurator 生成的示例代码：

在项目的 r_rg_cgc.c 文件中，额外增加了 R_SubOSC_Clock_XXX 函数和 R_RTCA0_Clock_XXX 函数。由于未能获取完整的函数实现代码，其具体功能尚不明确，推测可能与 RTC 上层应用的特定优化有关。该部分代码差异被列为重点排查对象。

随后，在故障设备和非 AUTOSAR 架构版本代码基础上，将对 SubOSC 初始化部分的修改，按右侧默认代码恢复。重新烧录后，32.768Khz 的时钟信号又出现。

将问题定位于 SubOSC 初始化部分的根源后，继续 Review 项目代码，并了解他们的上层软件设计思路：项目的 RTCA 驱动 SubSOC 初始化部分代码是非阻塞式分时操作的，即设置 SOSCST 稳定时间，但工程师在设置 SOSCE 使能 SubOSC 后就去干其他事了。于是做了以下验证：

把 SubOSC 初始化代码改为阻塞时串行操作后，即如下代码（主要是等待 SubOSC 稳定时间达到，判断 SOSCS=_CGC_SUBOSC_ACTIVE），未出现 32.768Khz 不起振的问题。

/* SubOSC setting */

        CLKCTL.SOSCST = _CGC_SUBOSC_STABILIZE_TIME;

       WPROTR.PROTCMD0 = _WRITE_PROTECT_COMMAND;

       CLKCTL.SOSCE = _CGC_SUBOSC_START;

       CLKCTL.SOSCE = (uint32_t) ~_CGC_SUBOSC_START;

       CLKCTL.SOSCE = _CGC_SUBOSC_START;

       while ((CLKCTL.SOSCS & _CGC_SUBOSC_ACTIVE) != _CGC_SUBOSC_ACTIVE)

       {

          NOP();

       }

SubOSC 的阻塞式串行操作和项目的非阻塞时分时操作的主要差别在于：非阻塞式分时操作可以优化系统启动时间，让 MCU 不必在启动阶段死等 SubOSC 的晶振的稳定时间。

实践分析表明，在设置了 SubOSC 稳定时间和使能 SubOSC 后，不必死等稳定时间到达，应该可以分时去做其他事情，到时自然会起振；但是应避免在 SubOSC 稳定时间到达之前去操作 SubOSC 时钟的后续通道，比如 RTCA。而这个 RTCA 功能部分代码也正是项目优化的目标，估计正好在 SubOSC 稳定时间到达之前开启了 RTCA 计时。经过上层应用代码审查，确认确实存在 SubOSC 稳定时间到达之前开启 RTCA 计时的操作。

重回 R7F7015873AFP-C 的芯片手册关于 SubOSC 的时序部分，在 Stabilization time /t_SSTB 稳定后，SOSCCLKATC 才会置位，表示 SubOSC Active。

而这个 Stabilization time /t_SSTB 稳定时间和晶振及外部谐振电路有密切关系，需要做匹配后得到一个经验值。

在所使用的晶振稳定时间的匹配报告中，这个稳定时间建议最大放到 700ms。

最终分析的原因是：在 MCU 启动过程中，设置了 SubOSC 初始化为非阻塞分时操作，在此期间未达到 SubOSC 所需的 Stabilization time /t_SSTB 稳定时间阶段，操作了 SubOSC 的后续时钟输出模块 RTCA，此过程将拉下 V_MOSCOP，导致晶振不起振。

通过在 R7F7015873AFP-C Demo 板上实验，如果精准模拟在 Stabilization time /t_SSTB 稳定时间之前操作 RTCA，XT2 的振荡波形有个明显被下拉的过程，也证明了该结论。

本文通过分析解决瑞萨 RH850 F1K/R7F7015873AFP-C  的 SubOSC 时钟信号不起振问题，介绍了 RH850 F1K 的 SubOSC 内部原理，软硬件设计要求；完整展示了定位排查问题的技巧和方法；大家可借此加深对振荡电路和 RH850 SubOSC 模块的了解，在开发过程中避免出现此类问题，同时掌握分析步骤。

欲了解关于更多瑞萨相关方案或技术信息，请与骏龙科技当地的办事处联系或点击下方「联系我们」，提交您的需求，骏龙科技公司愿意为您提供更详细的技术解答。