器件型号： AM3354
团队、
我们的客户在 AM3354x 处理器中的随机时间观察到看门狗复位
从以下寄存器读取的状态、由哪个 CPU 报告为 WD。
PRM 寄存器的基地址= 0x44E00000
从基址到全局 PRM 寄存器的偏移量 — 0xF00
使用我们的实验 代码时、在顶部和/proc/interrupts.中未观察到处理开销
您能否深入介绍该寄存器如何将复位原因报告为 WD — 作为替代我们必须进一步找出原因的所有其他调试选项分支的原因。
此致、
Madhurya
尊敬的 Madhurya：
感谢您联系 Sitara MPU 硬件应用团队。
因此、我理解客户观察到 AM335x PRM_RSTST 寄存器 WDT1_RST 位 4 设置为高电平：
Q1 ：在上电后的哪个阶段、客户会观察到 WDT1_RST 位从 0 变为 1：
a) AM335x ROM 引导、
b) 一些 Linux 引导加载程序、即 SPL/U-Boot
c) 在 Linux 用户（或内核）空间中执行实验代码时?
以下是 AM335x TRM 的两个摘录：
“公共 RAM 存储器映射“部分、“跟踪数据/表 “、“跟踪数据“部分、我了解 ROM 代码在 引导期间捕获了 SRAM 地址 0x4030CE4Ch 处的 PRM_RSTST 副本 — 它读取并存储 PRM_RSTST 复位原因寄存器、但不清除该寄存器。
问题 2：那么、全局看门狗热复位问题是否会出现在 AM335x ROM 启动阶段、因此 WDT1_RST 位的设置时间比您的应用程序启动的时间要早得多？
从硬件级别的角度来看、我会问：
问题 3 您是否可以观察到 VDD_MPU 和 VDD_CORE 电源轨的不稳定情况。 我怀疑这可能会 触发基于 PMIC PGOOD 的复位、看起来像看门狗复位。
问题 4 耦合到 WDT1 的 32kHz 振荡器源的噪声可能会导致计时器干扰、从而使 WDT1 看门狗计数器不可预测地跳变。
您能否提供一些 VDD_MPU、VDD_CORE 的准确示波图？ 可以在某些 AM335x CLKOBS 输出上观察到系统时钟（CLK_RC32K 或 CLK_32Khz — 在您的系统中为 WDT1 选择了哪个时钟）？
另请参阅器件勘误表_2.1_2.0 公告 1.0.24。 建议在向 AM335x 应用任何上电或热复位（包括 WDT1 复位）之前、仅使用 OPP_100 指定的 VDD_CORE 和 VDD_MPU 电压。
使用我们的实验代码 — 在顶部和 /proc/interrupts.中未观察到处理开销如果您已启用 WDT 延迟中断：严重地、如果重新加载事件在达到编程的延迟值 (WDT_WDLY) 之前发生、或者如果 WDT_WDLY 小于 WDT_WLDR、则不会生成中断。 这就是/proc/interrupts 不显示任何内容的原因—看门狗可以直接复位而无需触发中断。
我不是软件专家、但我认为、如果 Linux 系统在某个关键点挂起、则看门狗计时器可能仍然不被您的程序或 WDT 守护程序服务、并且它可能会过期、从而导致热复位。 这也可能在电源管理转换 期间发生：如果在暂停/恢复期间未正确处理看门狗、则可以延迟维护、使其超过超时时间。 WDT1 位于 PD_WKUP 电源域中、即使 MPU 断电也会保持有效状态。
您能否提供有关此寄存器如何将复位原因报告为 WD 的信息 — 替代我们必须为其创建的所有其他调试选项分支的原因。我不确定您在“见解“背后的意思是什么。 它是一个看门狗计数器溢出检测逻辑、记录 PRM_RSTST[4] WDT1_RST 位中的事件、该位 本身对热复位不敏感。 它只能在软件中修改、并在 POR 时被清除。
Q5：或者、您是否尝试了（如果您的设置/环境可能） 在存在调试符号且禁用看门狗计时器的情况下调试程序（应用 WD 禁用序列）。 或者、您可以让 WD 仍在运行、但在可能的最长超时时间内加载 WLDR=0？
我认为看门狗复位事件会破坏堆栈跟踪中的 CPU 上下文、因此您最好禁用 WDT。 或者、您可以使用专为您的用例构建的调试挂起机制。 如需更多信息、 请参阅 AM335x TRM 仿真下的看门狗计时器一节。 当 JTAG 调试器暂停 CPU 时、这会自动暂停看门狗。 每当恢复程序执行时、看门狗都会正常运行。 因此、它可在自由运行操作期间防止错误触发的复位、而不会丢失看门狗保护。
期待您的反馈！
谢谢
此致
Anastas Yordanov
