尊敬的专家:
我的客户发现他们的中断偶尔会被禁用。
他们看到的是 ISR 中的函数不再起作用。 在故障状态下连接到器件后、他们发现背接地仍在运行、但 INTM 设置为 1、且 IER 设置为全零。

手动将 INTM 和 IER 设置为正确的值后、ISR 将再次正常工作。
它们不使用中断嵌套。
在这种情况下、什么因素可能导致 INTM 和 IER 被禁用? 当这两个寄存器设置为意外值时、是否有任何方法可以捕获?
此致、
挂起
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
尊敬的专家:
我的客户发现他们的中断偶尔会被禁用。
他们看到的是 ISR 中的函数不再起作用。 在故障状态下连接到器件后、他们发现背接地仍在运行、但 INTM 设置为 1、且 IER 设置为全零。

手动将 INTM 和 IER 设置为正确的值后、ISR 将再次正常工作。
它们不使用中断嵌套。
在这种情况下、什么因素可能导致 INTM 和 IER 被禁用? 当这两个寄存器设置为意外值时、是否有任何方法可以捕获?
此致、
挂起
您好 Hang、
每次 CPU 接收中断时、IER 和 INTM 都将压入堆栈、并在上下文保存期间由硬件自动清除。 然后、在上下文恢复期间、IER 和 INTM 将自动从堆栈中弹出。
我希望他们建议 每当写入零值时、尝试在 IER 和 INTM 寄存器上执行硬件观察点以停止、但这可能会由上述过程触发。 他们仍然可以尝试这种方法 — 我不确定它是否会从上下文恢复执行的写入中触发。
另一个建议是在后台循环中的整个代码期间定期轮询 IER 和 INTM 寄存器。 由于没有启用嵌套、因此后台循环中的任何时候都不应清除这些寄存器。 如果满足(清除)条件、它们可以添加一个 ESTOP0、并查看在后台循环中发生这种情况的相对位置。
此致、
Delaney