[参考译文] TMS320F28069M：在请求 ISR 或 ISR 结束时的 PIEACK？ （和每一个的副作用）

您好：

专家在星期四之前不在办公室、请预计回复会延迟。

您好：

谢谢你的耐心,当我离开办公室.  

1. 您能否将代码作为文件插入？ 我无法在图像中看到它。
2. 您链接到的线程不询问嵌套情况、它们只是讨论一个常规中断情况、在该情况下每个 ISR 将运行到完成。  

此致、

Delaney

尊敬的 Delaney：感谢您的答复。

1.它现在应该很清楚。
2.当 PIEACK 是在请求或 ISR 结束时完成的,每一个的副作用是什么 ?

  2.1 如果在开始时执行、可能会导致堆栈溢出？

  2.2 如果在结束时完成、可能会丢失挂起的中断？

注意：我使用掩码为：_none。 Sweet Spot 是否会像 Use _self 选项一样、并在开始时进行确认以避免当前 PIE 组的堆栈溢出？  

3.我想知道为什么解决方案背后的原因： TMS320F28069M：PIE Group1（计时器 0）在严重 SCI Rx 期间中断 — C2000 微控制器论坛 — C2000︎ 微控制器 — TI E2E 支持论坛。 由于丢失的中断来自不同的 PIE 组、并且弄清楚 ISR 顶部的可解决该问题。  

尊敬的 Anirban：

感谢您重新上传图片、我现在可以清楚地看到它们。  我将研究您的问题、并在下周初回复您。

此致、

Delaney

尊敬的 Anirban：

为了更新、我仍在研究这个问题、并将尝试在明天得到回复。

此致、

Delaney

感谢您发送编修

尊敬的 Anirban：

ACK 标志的主要用途是防止在 ISR 执行时丢失来自同一组的中断。 ACK 在物理上阻止设置给定组的 IFR 位。 要从 CPU POV 执行中断、请参阅以下序列：

前面的步骤是 ACK 开启。 因此、此处要注意的步骤顺序如下：

1. 如果开关闭合、则中断会通过组 x 的 ACK
2. ACK 在信号传递后自动打开
3. IFR 已标记
4. 如果开关闭合、IER 允许信号通过
5. 如果开关闭合、INTM 允许信号通过
6. IFR 自动清除
7. IER 会自动打开
8. INTM 标志自动打开
9. ISR 执行

为了接收进一步的中断、需要在步骤 9 中的某个时刻再次关闭 ACK。 关键在于在清除 IFR 之前打开 ACK（阻止同一组中的进一步中断进行）。 清除 IFR 后、可以在之后的任何时刻关闭 ACK。 不管它是在步骤 9 的开始还是在最后  

我不确定为什么另一个 E2E 主题建议将 ACK 移至 ISR 的开头、或者为什么这样可以解决该其他问题中的任何问题。

但是、如果您正在进行中断嵌套、建议根据您正在执行的嵌套类型遵循特定的序列。 请查看我对 该线程的第一个回复 、其中概述了所有不同的嵌套场景以及代码在每个 ISR 中应如何查找。 在这种情况下、您需要严格遵循此处的顺序、因为如果任何事情发生顺序不当、可能会出现各种潜在问题。

您能否说明您尝试执行的嵌套设置和特定的中断、以便我可以告诉您是否存在任何栈溢出风险？

此致、

Delaney

 感谢您发送编修。我们会重新检视您的建议。  

然而,我想强调上下文和我的具体情况:

1.using SYSBIOS：自动嵌套： 已启用（默认） ：  

2.使用_None 作为 cfg 文件中的 maskSetting： MaskingOption_none — 不禁用中断

var hwi6Params = new Hwi.Params();
hwi6Params.instance.name = "ECAP3_INT";
hwi6Params.enableAck = false;
hwi6Params.maskSetting = xdc.module("ti.sysbios.interfaces.IHwi").MaskingOption_NONE;
Program.global.ECAP3_INT = Hwi.create(58, "&vEcap3Interrupt", hwi6Params);

var hwi13Params = new Hwi.Params();
hwi13Params.instance.name = "ECAP4_INT";
hwi13Params.enableAck = false;
hwi13Params.maskSetting = xdc.module("ti.sysbios.interfaces.IHwi").MaskingOption_NONE;
Program.global.ECAP4_INT = Hwi.create(59, "&vEcap4Interrupt", hwi13Params);
var hwi14Params = new Hwi.Params();

debug\configpkg\package\cfg\build_p28fp.c：

    {/* instance#6 */
        0,
        (xdc_UInt)0x3a,  /* intNum */
        1,  /* enableInt */
        0,  /* enableAck */
        (xdc_Bits16)0x0,  /* disableMask */
        (xdc_Bits16)0x0,  /* restoreMask */
        (xdc_Bits16)0x8,  /* ierBitMask */
        ((xdc_UArg)(0x0)),  /* arg */
        ((xdc_Void(*)(xdc_UArg))((xdc_Fxn)vEcap3Interrupt)),  /* fxn */
        ((xdc_UArg)0),  /* irp */
        ((void*)0),  /* hookEnv */
    },
    {/* instance#7 */
        0,
        (xdc_UInt)0x3c,  /* intNum */
        1,  /* enableInt */
        0,  /* enableAck */
        (xdc_Bits16)0x0,  /* disableMask */
        (xdc_Bits16)0x0,  /* restoreMask */
        (xdc_Bits16)0x8,  /* ierBitMask */
        ((xdc_UArg)(0x0)),  /* arg */
        ((xdc_Void(*)(xdc_UArg))((xdc_Fxn)vEcap5Interrupt)),  /* fxn */
        ((xdc_UArg)0),  /* irp */
        ((void*)0),  /* hookEnv */
    },

ISR 运行而不禁用任何中断：  

    C:\ti\bios_6_83_00_18\packages\ti\sysbios\family\c28\Hwi.c:L1145
    
    Void Hwi_dispatchCore(Int intNum){ 
    //..
    
    /* call the user's isr */
    if (Hwi_dispatcherAutoNestingSupport) { // enabled
        if (Hwi_zeroLatencyIERMask == 0) {
            /* Propagate self bit which is auto cleared by hardware */
            IER |= hwi->ierBitMask;

            oldIER = IER;
            IER &= ~hwi->disableMask;

            __enable_interrupts();
            (hwi->fxn)(hwi->arg);
            __disable_interrupts();

            IER |= (hwi->restoreMask & oldIER);
        }

3. ECAP3/4 在 ISR 开始时启用 PIEACK。

现在、在此配置中、当 ECAP4 ISR 正在执行且 PC 刚刚完成时 PIEACK-ED （ISR 开始时） 会发生以下情况：

答：现在、任何其他 ECAPx 是否可以干扰/抢占 ECAP4 ISR（？）

b. 现在、 是否可以相同的 ECAP4（如果从外部源重新触发）、导致占先并形成递归（？）

提前感谢您。

嗨 Delaney、您是否发现 此情景中存在任何潜在风险？  

尊敬的 Anirban：

我很抱歉；我被其他任务搁置。 我将尝试在本周结束前对您作出回应。 很抱歉耽误你的时间。

此致、

Delaney

当然、谢谢 Delaney。

尊敬的 Anirban：

很抱歉耽误你的时间。 从 ePIE 的角度来看、您通常希望 严格遵循此主题中所述用例的 ISR 实现、以避免出现任何问题。 我循环一下 SYS BIOS 专家对此进行评论、看看他们是否看到任何问题、或者在您的案例中是否需要更改 ISR 实现。

此致、

Delaney

当 您在 Hwi 配置中将 enableAck 设置设置为 true 时、SYS/BIOS 将在调度程序进程的早期（在 Hwi 函数运行之前）执行 ACK。 我认为,将 enableAck 设置为 false ,并在 Hwi 函数的最末端自行调用它,会对堆栈溢出的可能性产生显著影响。 即使在 Hwi 函数运行后、仍有将在中断上下文中执行的 Hwi 调度器的后一半。

如您所指出的、如果您的掩码设置为 none、则无论 ACK 状态如何、其他组的中断都能够嵌套。 对于同组中断、它将能够在设置 ACK 后执行、因此它将优先于 Hwi。

Whitney