[参考译文] TMS320F28P650DK：由于未清除 PIEACK、不会触发组 9 中断

您好 Hang、

如果它们使用中断嵌套、 您能否让它们列出系统中使用的所有中断以及它们的嵌套方式？ 请参阅此处有关中断嵌套的指南 — 确定它们正在执行的嵌套类型以及属于哪种情况非常重要。 如果嵌套实现错误、则可能会导致类似这样的意外行为。  

此致、

Delaney

尊敬的 Delaney：

感谢您提供详细信息。 它们的用例为案例 3（最低）、其 ISR 与建议的用例不同。 我会要求他们根据建议作出更改

然而、您能否进一步解释一下它们的 ISR 运行如何 引领 PEIACK 置位、但未设置 IFR？

此致、

挂起

您好 Hang、

让我看看这个、然后回到您那里。

此致、

Delaney

您好 Hang、

当 ISR 分支到正常（非嵌套）的情况时、会发生以下步骤：

1. 硬件–中断传播到 CPU 之前
   1. 一旦信号通过并设置 IER、PIEACK 就会打开
2. 硬件–中断传播到 CPU 后
   1. IER 寄存器+ INTM 位被压入堆栈
   2. 清除 IFR
   3. 清除 IER
   4. 打开 INTM
   5. 获取矢量
   6. 清除 PIEIFR
3. 软件
   1. 【中断执行】
   2. 关闭 PIEACK  
4. 硬件
   1. IER 从堆栈中弹出
   2. 从栈中弹出的 INTM（关闭）

当 ISR 分支到时、IFR 将由硬件自动清零。 ACK 也会由硬件自动打开（设置）。  

如果没有理解所有启用的中断、用户定义的优先级以及它们如何在每个 ISR 中实现嵌套、就很难说 ACK 是如何保持打开状态。

此致、

Delaney

尊敬的 Delaney：

因此、根据 PIE 标志的状态、它看起来像是在步骤 2b 和 2f 之间嵌套了一个中断（或第 9 组中的另一个中断）、并且从不回来恢复执行。

在组 9 中、还启用了 SCI TX 和 RX 中断。 SCI RX 是我之前所指的“SCI 中断“的中断。  

TX 和 RX 中断都作为第一个 POST 中的代码片段实现

ISR(){
    EINT; // Yes they uses nesting
    DoSomething();
    Clear_SCIA_InterruptFlag();
    Clear_ACK(Group9);
    DINT;
}

后台的中断（包括其他组中的中断）都具有相同的实现方式。  

是否可以解释这种实施方式如何导致这个问题？ 或者、您能举个例子来说明这种情况是如何发生的吗？

此致、

挂起

您好 Hang、

明天我将作出回应。

此致、

Delaney

您好 Hang、

对延迟深表歉意。 我认为 DINT 和 ACK 清除顺序的差异不应该有所不同、因为 ACK 无论如何都需要多个周期才能生效、因此 DINT 也应该在其实现中首先生效。  

澄清一下、他们没有更改任何 ISR 中的 PIEIER、PIEIFR、IER 或 IFR 寄存器、是这样吗？ 如果是、优先级方案与 PIE 表中相同、这意味着 SCI 中断在组 9 中的优先级非常低。

1. 当 SCI 中断停止分支时、他们能否验证其系统中的其他 ISR 是否正常工作？
2. 更高优先级组中的其他 ISR 可能会阻止 SCI 中断完成执行。 它们是否能够在每个 ISR 中使用唯一的 GPIO 切换进行测试、以及测试何时发生行为时将分支哪些 ISR？

此致、

Delaney

尊敬的 Delaney：

最低 PIE 优先级组 9、SCI A RX/TX INT、SCI B RX/TX INT 中有 4 个 INT。

当前组没有使能 IER、当前 PIE 没有清除 ACK [如果存在 ACK ]、EINT 之前没有等待 1 个周期、如果没有这三个步骤、会发生什么问题？

嗨、Helen、

您发送的屏幕截图中概述的步骤仅适用于优先级最低的单个 ISR、即 SCIB_TX。  在 EINT 之前不清除 ACK + NOP  的唯一问题是、同一组中的其他中断无法嵌套在内部 (SCIA_RX、SCIA_TX 和 SCIB_RX)。 我认为缺少 IER 启用步骤可能会导致一些问题、因为 IER 将在分支到 ISR 的过程中自动清除。 让我再做一些集思广益、以了解这些问题是什么。

此致、

Delaney

尊敬的 Delaney：

这表示由于设置了 PIEACK9、信号从 PIEIFR9.1 到 IFR9 的传播被阻止。

然后、我们尝试通过软件复位 SCI-A、但 SCI 通信不会恢复。

之后、我们清除 PIEACK9、通信已恢复（可以正确进入中断）。

似乎 PIEACK9 是从导致此问题的中断意外设置出来的。

在本例中、我认为 IER 是对的、只有 PIEACK 保留 1。  

嗨、Helen、

我看到了、是的。 他们能否提供一个它们已启用的所有中断的列表、并确认它们是否为每个 ISR 使用相同的以下结构？

ISR(){

1. EINT；//是、它们使用嵌套
2. Dosomething ();
3. CLEAR_SCIA_InterruptFlag ();
4. CLEAR_ACK (group9)；
5. DINT；

}

我想这仍然是在 上面的第 1 行和第 4 行之间嵌套了一个不同的中断、阻止 CPU 每次回来完成执行。 因此、ACK 保持打开、该组未来不会中断。 了解应用程序中其他中断的性质会有所帮助。

此致、

Delaney

尊敬的 Delaney：

阻止 CPU 每次返回完成执行。

嵌套中断如何导致这种情况？ 当嵌套 ISR 完成时、CPU 应始终返回到前一个 ISR（除非 CPU 永远卡在嵌套 ISR 中）、对吧？ 任何可能导致这种情况的示例？

您好 Hang、

是的,要做到这一点,我相信 CPU 必须永远嵌套。 可能每次分支回原始 ISR 时、都会标记另一个更高优先级的中断并传播到 CPU、因此 CPU 会持续进入嵌套中断、永远不会完成原始中断。  
让我咨询另一位专家、看看他们是否有其他想法。

此致、

Delaney

您好 Hang、

客户是否能够在多块电路板上重现此问题？ 它们能否在 Launchpad / controlCARD 上重现问题？ 我只想排除任何硬件问题。

此致、

Delaney

所有 ISR 操作如下：

CPU1 Timer ISR、I2C ISR、SCIA RX/TX ISR、SCIB RX/TX ISR 类似：

｛

1. EINT；//是、它们使用嵌套
2. Dosomething ();
3. CLEAR_SCIA_InterruptFlag ();
4. CLEAR_ACK (group9)；
5. DINT；

}

ADC ISR、IPC1 ISR、IPC2 ISR、IPC3 ISR  类似：

｛

1.DoSomething ()

2.清除确认

}

嗨、Helen、

听起来不错、感谢您澄清了其他中断的 ISR 布局。 基于此、中断看起来只能嵌套在  CPU1 Timer ISR、I2C ISR、SCIA RX/TX ISR、SCIB RX/TX ISR、而其他中断不能嵌套其他 ISR 内部。 另外、他们是否能够回答上面的这个问题？

客户是否能够在多个电路板上重现此问题？ 它们能否在 Launchpad / controlCARD 上重现问题？ 我只想排除任何硬件问题。

此致、

Delaney

是的、可以在多个电路板上重现此问题。 哪种硬件问题会导致此问题？