[参考译文] TDA4VL-Q1：一些关于看门狗溢出的问题、希望能解答

您好、Kong、

您能告诉我更多的细节吗?

您使用的是哪个 SDK 版本？

您提到的是 PDK 看门狗驱动程序还是 MCAL 驱动程序？

我注意到 RTI_RTIDWDPRLD 的值与配置的

我记得这是一个预定义的宏,请问你是怎么配置的?

此致

Tarun Mukesh

您好、我们使用的 SDK 版本是 10.0.0、使用 MCAL 驱动看门狗

我注意到 RTI_RTIDWDPRLD 的值与配置的

timeOutVal 通过 EB 配置、我的意思是 RTI_RTIDWDPRLD 寄存器的值与用 EB 配置的 timeOutVal 匹配、即我们随 EB 更改的 timeOutVal 的值被写入到 RTI_RTIDWDPRLD 寄存器、但 ESM 中断触发的周期仍约为 1.7s。我通过芯片参考手册了解的内容、并将把 rtimePRIDVal 配置写入 RTI_DWDLD_OUTLD 寄存器的时间 计数器将在启用看门狗后递减计数、计数值为 RTI_RTIDWDPRLD 寄存器的值、如果计数器计数到 0 时未执行正确的看门狗馈送操作、则将出现不可屏蔽的看门狗溢出中断或系统复位、来自该代码的看门狗溢出中断是 ESM 中断、但在实际测试中、ESM 中断的周期固定为约 1.7s 并且不会随着 EB 配置的 timeOutVal 的变化而变化、这显然不是我们预期的那样

您好：

您能和我分享 RTI 内核寄存器转储吗？ 我们需要了解 timeoutVal 是否实际写入寄存器

此致

Tarun Mukesh

您好、是否要查看 RTI 相关寄存器的值？

您好：

是。以下为您的特定实例注册。

需要确定您配置的 timeoutVal 以及确切写入预加载寄存器的内容。

此致

Tarun Mukesh

需要注意的是、调试模式只关注寄存器值、看门狗溢出的实际测试并未使用调试、而是使用串行端口打印。我们设置的 timeOutVal 为 2000、配置代码如下图所示

您好、Kong、

我检查一下寄存器值并返回给您。

此致  

Tarun Mukesh  

大家好、我已经提供了 RTI 寄存器的状态、您能帮助我尽快看到 ESM 中断触发周期的问题、我们的工程很匆忙、此外、我们更改了看门狗溢出后的操作、从执行不可屏蔽中断更改为系统复位、调试模式、查看 RITWWDRCTRL 寄存器的值已更改为 XN0x5、 但在不馈送看门狗时、看门狗溢出看不到系统复位现象、执行 WDG_ generateSysRest 函数（在此函数中，先将 0xE51A 写入寄存器 RTIWDKEY、然后写入 0x4444）也未观察到系统复位现象、根据参考手册和寄存器简介、首先将 0xE51A 写入寄存器 RTIWDKEY、然后将导致系统复位 0x4444 调试模式观察寄存器 WDSTATUS 的 KEYST 位也设置为 1、因此也请帮助我看看这个问题

您好、我尝试删除 ESM 中断处理程序中的看门狗馈送函数、ESM 中断触发周期已更改、尽管实际值的理论值有错误（例如 timeoutVal = 1000ms）、实际测试中断触发周期约为 644ms、timeoutVal = 1500ms、实际测试中断触发周期约为 966ms、timeoutVal = 2000ms、实际测试中断触发周期约为 1300ms 实际测试中断触发周期约为 1620ms、这表明实际值的倍数与理论值的倍数大致相同。 我想问、在看门狗溢出中断中只清除中断触发标志（清除 RTIWDSSTATUS 寄存器的值）计数器不会重新加载、导致看门狗溢出中断的触发周期不会改变、添加看门狗馈送功能后重新加载计数器的值、以便看门狗溢出中断的触发周期会发生变化、是否建议在触发看门狗中断后执行处理流程？

您好、Kong、

我尝试在 ESM 中断处理程序中删除看门狗馈送函数、ESM 中断触发周期已更改、

很棒！！ 这可确认超时值 (RTIDWDPRLD) 有效、因为更改此值会更改看门狗溢出中断间隔。

hich 显示实际值的倍数与理论值的倍数大致相同

理论超时和实际超时之间可能存在差异、原因可能是时钟源频率或预分频器设置。

您 说得完全正确：

在看门狗溢出中断中、如果只清除状态标志 (RTIWDSSTATUS) 并且未馈送看门狗、则不会重新加载计数器、因此看门狗将在同一超时周期后再次溢出。 只有馈送看门狗（通过写入适当的 KEY 寄存器）才会重新加载计数器。

触发看门狗中断后是否有建议的处理流程？

a)

1.记录故障/捕获错误状态。
2.清除看门狗中断状态 (RTIWDSTUS )。
3.不要馈送看门狗—如果错误不可恢复、则允许系统重置。

 非常适合在系统无法正确恢复或重新启动时希望强制复位的故障恢复用例。

b)

1.确定系统是否运行良好、以便继续。
2.如果是,则馈送看门狗（通过密钥寄存器写入重新加载计数器）。 清除 RTIWDSTATUS。

3.如果没有,只清除旗帜。 允许看门狗再次到期（最终导致复位）。

 用于具有多次重试尝试的系统。

此致

Tarun Mukesh

Hich 表明实际值的倍数与理论值的倍数大致相同

理论超时和实际超时之间可能存在差异、原因可能是时钟源频率或预分频器设置。

[/报价]

当前为 RTI0 设置的时钟为 12.5MHz。 我是否可以询问、哪种时钟频率配置可以允许理论超时持续时间与实际超时持续时间非常接近、从而更大限度地减少理论值和实际值之间的差异？

此外、我们已将看门狗溢出后的操作从执行不可屏蔽中断更改为系统复位、调试模式已将 RITWWDRXNCTRL 寄存器的值更改为 0x5、但在不馈送看门狗时看门狗溢出不会出现系统复位现象、首先在 WDRTRRKEY_寄存器中写入 WD11A、 然后写入 0x4444) 也没有观察到系统复位现象、根据参考手册和寄存器的介绍、首先将 0xE51A 写入寄存器 RTIWDKEY、然后写入 0x4444 将导致系统复位、并且调试模式观察寄存器 WDSSTATUS 的 KEYST 位也设置为 1、请帮助我同时查看这个问题

此外、您能帮助我了解这个问题吗？ 为什么在不导致复位的情况下、看门狗的馈送序列会变得无效？ 此外、当我将寄存器 RTIDWWDRXNCTRL 配置为值 0x5 时、根据寄存器的说明、写入 0x5 时、在看门狗溢出时应该会导致复位。 但是、我的观察结果没有显示发生了任何复位。

[/quote]

您好：

RTI0 当前设置的时钟为 12.5MHz。 我是否可以询问、哪种时钟频率配置将允许理论超时持续时间与实际超时持续时间非常接近、从而更大程度地减小理论值和实际值之间的差异？

我使用默认示例检查了 12.5MHz 的 2000ms、我以 90%的频率服务了 5 次、并且得到了大约 10s 的实际超时。检查是否正在设置任何预分频器值。

此外、您能帮助我了解这个问题吗？ 为什么在不导致复位的情况下、看门狗的馈送序列会变得无效？ 此外、当我将寄存器 RTIDWWDRXNCTRL 配置为值 0x5 时、根据寄存器的说明、写入 0x5 时、在看门狗溢出时应该会导致复位。 但是、我的观察结果未显示发生任何重置。

我们有一个看门狗 IP 限制、即不复位内核、如果看门狗未得到处理、则会触发 ESM 中断。 此 ESM 中断应向 PMIC 发送信号进行复位。

我们在 超时计数后调用 API WDG_generateSysReset。 这将生成一个 ESM 中断。

此致

Tarun Mukesh

请在 SDK /mcusw/mcal_drv/mcal/examples/Wdg/WdgApp.c.中查看此示例

我们的时间值为 2s、我们将狗（服务）馈送 5 次、10s 后、我正好得到 ESM 中断。

此致

Tarun Mukesh

您好、

我使用默认示例检查了 12.5MHz 下 2000ms 的时间、我以 90%的频率提供了 5 次服务、而实际超时时间大约为 10s。检查您是否正在设置任何预分频器值。

看门狗模块的时钟直接在 board_pll.c 的 gBoardPllClkCfgMcu[]中设置、器件 ID 为 295 (MCU_RTI0)、时钟源 ID 为 4 (DEV_MCU_RTI0_CLK_PARENAL_J7AM_WAKEUP_16FF_WKUP_0_WKUP_RCOSC_12PPM_CLK)。 时钟频率为 12,500,000、并且没有设置预分频器。 串行端口打印是否可能影响中断周期、或者是否有设置预分频器的代码的另一部分？ 我需要对此进行调查。您是通过调用 Wdg_Power AndClkSrc() 来设置时钟、还是在 EB 的 MCU 模块中配置时钟？

在 超时计数后、我们正在调用 API WDG_generateSysReset。 这将生成一个 ESM 中断。

您是否意味着在 ESM 中断期间调用 WDG_generateSysReset 会导致系统复位？ 不过、我在看门狗触发的 ESM 中断处理程序中调用了 WDG_generateSysReset、并且没有观察到系统复位。 我注意到、看门狗不会再次触发中断、并且电压和电流也没有明显波动。 此外、代码没有重新执行主要功能来进行重新初始化、并且电路板上的指示灯保持持续亮起、而不会关闭和重新打开。 因此、我认为调用 WDG_generateSysReset 不会导致系统复位。 您能解释一下原因吗？

您好：

我将离开、直至星期一。 请预计响应会延迟。

此致  

Tarun Mukesh  

因此、我认为调用 WDG_generateSysReset 不会导致系统复位。 您能解释一下原因吗？

• 如上所述、看门狗 IP 不会复位内核、只会生成 ESM 中断。
• 生成 ESM 中断后、您需要处理驱动 PMIC 的 ESM 中断。
• WDG_generateSysReset API 不用于生成系统复位。 它只生成一次 ESM 中断、然后明确地您需要将 ESM 中断驱动到 PMIC 并对 PMIC 进行编程以进行复位。

您好、感谢您的患者回复。 我是否正确理解看门狗溢出只会产生 ESM 中断而不会直接导致复位？ 如果需要复位、则必须通过 PMIC 实现。 此外、我想问一下我们如何在 ESM 中断中通过 PMIC 生成复位、因为我还没有看到有关 WdgApp.c 中复位的任何实现 我能想到的唯一方法是在 Mcu_Perform 中断函数内调用 ESM.Reset()。 这种做法是否合理和可行？ 如果不可行、您能否为我们提供合理的解决方案？

您好：

。 我是否正确理解看门狗溢出只会生成 ESM 中断并且不会直接导致复位？

是的。 完全正确。

此外、我想问我们如何在 ESM 中断中通过 PMIC 生成复位、因为我没有看到有关 WdgApp.cc

是 WdgApp 示例不会告诉如何通过 PMIC 进行复位。

它介绍如何通过 ESM 驱动 mcu_safety_error/SOC_safety_error 引脚。

 MCU_SAFETY_ERROR_SOC_SAFETY_ERROR 引脚连接到 PMIC。 根据 PMIC 编程、它应该复位内核。

（驱动 PMIC 复位内核超出看门狗模块的范围）

一旦  MCU_SAFETY_ERROR_SOC_SAFETY_ERROR 引脚被驱动为高电平、那么在 PMIC 中、您应进行编程以复位相应的内核。

我能想到的唯一方法是在 Mcu_Perform 中断函数内调用 esm.Reset()。 这种做法是否合理和可行？ 如果不可行、您能否为我们提供合理的解决方案？

否、您不能使用此功能。 此 API 能够进行系统复位、但不能进行内核复位。

此致

Tarun Mukesh

您好、感谢您的回复、我首先会研究如何将 ESM 的错误信号与 PMIC 相关联、但还有一个问题您没有回复我、WDG_generateSysReset 的作用是什么？ 在此函数中、首先写入 RTI_RTIWDKEY 0xE51A、然后写入 0x4444、根据手册“如果任何错误的值写入 RTI_WDKEY 寄存器、看门狗复位将立即发生“、我的理解是写入错误序列会立即导致看门狗复位、但从您之前的回复来看、看门狗无法复位、所以我想直接询问哪个 SysReset 函数？ 调用函数时会发生什么情况？ 是否将触发 ESM 中断？ 期待您的答复

您好：

WDG_generateSysReset 扮演什么角色？ 在此函数中、先写入 RTI_RTIWDKEY 0xE51A、然后写入 0x4444、根据手册“如果将任何错误的值写入 RTI_WDKEY 寄存器、则会立即发生看门狗复位“、

看门狗复位和系统复位之间存在差异。调用 WDG_generateSysReset API 来进行系统复位。

在 WDG 到期后调用 WDG_generateSysReset API。 它在 Wdg_Set  TriggerCondition API 中实现、且超时值 = 0。

调用函数时会发生什么情况？ 是否将触发 ESM 中断？ 期待您的回复

是的。 生成 ESM 中断。

当 WDG 到期时、RTI/WDG 硬件无法复位 SoC、而可以将 SoC 的一个引脚置为有效。 预计外部实体（如 PMIC）将监控该引脚并在引脚驱动为低电平时将 SoC 复位。 ESM 以两种方式报告错误。

• 器件中处理器的中断。 这允许器件分析并尝试从错误中恢复。
• 外部 ERROR 引脚。 这允许 SoC 外部的系统监测是否存在潜在的致命错误（器件无法自恢复的错误）。 外部 I/O（MCU_SAFETY_ERRORn 引脚）将在最短的时间内保持置位（低电平有效）。 在这段时间后、如果内部处理器清除了错误、引脚将变为无效状态（高电平）。 如果在这段时间内它没有变为不活动状态、则外部代理应进行干预、因为可能存在不可恢复的错误。

此致

Tarun Mukesh