为什么 RESC 寄存器中的 POR 和 XRSn 位不会清除

您的代码是正确的、但 Boot-ROM 会在您的应用程序运行之前清除这些位 、然后重新设置这些位以反映当前复位状态。 这是特定于 F2837xD 的硬件/引导 ROM 行为、不是代码中的错误。

近况如何

TMS320F28375D 技术参考手册 (SPRUHM8K) 明确指出：

“在 POR 之后、设置 RESC 中的 POR 和 XRSn 位。 这些位随后被引导 ROM 清除。“ [1]

而对于 POR 位、具体来说：

“此位由 Boot-ROM 清除。 因此、 应用程序无法使用此位 来确定 POR。“ [2]

这同样适用于 XRSn：

“只要 XRS 出于任何原因被驱动为低电平、RESC 寄存器中的 XRSn 位就会被置位。 此位随后被引导 ROM 清除。“ [1]

所以顺序是：

1. 发生上电→硬件设置 POR 和 XRSn 位（值= 0x3）
2. 引导 ROM 执行→会清除这两个位
3. 引导 ROM 完成→您的应用程序将启动
4. 到代码运行时、这些位反映 引导 ROM 后的状态

3 读取的值表明这些位正在重新置为有效、或者 Boot-ROM 清除的行为在您的配置中未达到预期。 但是、数据表可以清楚地看出： 您的应用程序无法可靠地使用 POR/XRSn 位 、因为 Boot-ROM 负责清除这些位。

寄存器定义确认写入 1 以清除

虽然该寄存器 被定义为 R/W1C（写入 1 以清除）[2]、但引导 ROM 的干预意味着您的应用程序级写入与引导过程对这些位的处理相竞争。

F2837xD 上的硬件限制

这是一个已知的架构限制。 较新的 F2838x 器件添加了一个 专用的 RESCCLR 寄存器、 专门用于解决此问题：

“添加了一个新的复位原因清除 (RESCCLR) 寄存器、以清除复位原因 (RESC) 寄存器中的状态。“ [3]

这种增强的存在正是因为 F2837xD（和类似的先前器件）缺少一种干净的应用级机制来清除这些位。

权变措施

由于您无法在 F28375D 上可靠地清除或使用应用代码中的 POR/XRSn：

• 启动时读取一次 RESC 寄存器 、并将该值存储在软件变量中
• 使用软件标志 来跟踪您是否已处理重置原因
• 重点关注 引导 ROM 未清除且行为符合预期的其他 RESC 位（WDRSn、NMIWDRSn 等） SysCtl_clearResetCause()

为了帮助进一步完善这一点、了解以下内容会有所帮助：

• 您的应用是否需要区分 POR 和 XRS 以实现功能逻辑（如果是，可能需要替代检测方法）
• 无论您使用标准 TI 引导 ROM 还是自定义引导配置
• C2000Ware 或 driverlib 版本、因为实现细节可能会有所不同

1. TMS320F2837xD 技术参考手册 — 复位部分
2. TMS320F2837xD 技术参考手册 — RESC 寄存器字段说明
3. F2837x 至 F2838x 迁移指南