2416003_zh-CN

[#1]

当 OTP_CFG_ASIL.WD_DIS = 1 时，FS85 一直卡在 INIT_FS 状态——这是预期行为吗？

您好，

我们正在启动一块带有 FS85（故障保护 SBC）的板子，但故障保护状态机永远不会离开 INIT_FS（即使 MCU 在配置的窗口周期内发送连续的看门狗刷新，FS_STATES.FSM_STATE 也无限期地保持在 6 / INIT_FS）。

根据数据手册（修订版 9，第 14.3 节，第 18 页）： “第一次成功的看门狗刷新会关闭 INIT_FS。”就我们而言，OTP_CFG_ASIL.WD_DIS = 1（OTP 已禁用看门狗监控）。

支持在卡住时读取寄存器（这与看门狗评估逻辑根本不运行的情况完全一致）：

• FS_I_WD_CFG.WD_ERR_CNT = 0， WD_RFR_CNT = 0（永不移动）
• FS_DIAG_SAFETY.BAD_WD_DATA = 0， WD 时序错误 = 0（永不锁定）
• FS_STATES.REG_CORRUPT = 0， OTP_CORRUPT = 0（排除 INIT_FS 寄存器/寄存器非值不匹配的情况）

问题： WD_DIS = 1 是否会在结构上阻止离开 INIT_FS（因为当 WD 被 OTP 禁用时，永远无法生成关闭 INIT_FS 的“良好看门狗刷新”事件）？或者，当 OTP 禁用看门狗时，是否有其他已记录的路径可以关闭 INIT_FS 并到达 NORMAL_FS？

数据手册第 14.1/14.3 节状态 VALID_WD = 0“当 WD 被 OTP 禁用时”，但没有明确说明 INIT_FS -> WAIT_ABIST2 转换的后果。如有任何说明或相关应用笔记的链接，敬请指正。

谢谢你，索菲。

FS85&FS84Re: FS85 stuck in INIT_FS forever when OTP_CFG_ASIL.WD_DIS = 1 — is this expected?

你好 sobo

再会！

在调查过程中，我发现了一个类似案例的信息，我正在与负责审查该案例的同事一起审查；但是，鉴于该案例的性质，您需要在我们的官方网站上开一个工单，以便我们能够更自由、更安全地共享信息。

感谢您的理解。

祝你今天过得愉快，一切顺利。