主题中讨论的其他器件:SYSBIOS
工具/软件:
关于以下主题、
我有以下问题:
- 为什么下面的工作原理? 由于 Timer0 和 SCIRXINTA/B 是两个不同的 PIE 组。
- 当 PIEACK 被确认时、在 ISR 开始时、它可能会导致栈溢出(由于可能的嵌套中断)、那么它是否安全?

TMS320F28069M:严重 SCI Rx 期间的 PIE 组 1(计时器 0)丢失中断 — C2000 微控制器论坛 — C2000︎ 微控制器 — TI E2E 支持论坛
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.
工具/软件:
关于以下主题、
我有以下问题:

TMS320F28069M:严重 SCI Rx 期间的 PIE 组 1(计时器 0)丢失中断 — C2000 微控制器论坛 — C2000︎ 微控制器 — TI E2E 支持论坛
尊敬的 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:
ACK 标志的主要用途是防止在 ISR 执行时丢失来自同一组的中断。 ACK 在物理上阻止设置给定组的 IFR 位。 要从 CPU POV 执行中断、请参阅以下序列:

前面的步骤是 ACK 开启。 因此、此处要注意的步骤顺序如下:
为了接收进一步的中断、需要在步骤 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(如果从外部源重新触发)、导致占先并形成递归(?)
提前感谢您。
当 您在 Hwi 配置中将 enableAck 设置设置为 true 时、SYS/BIOS 将在调度程序进程的早期(在 Hwi 函数运行之前)执行 ACK。 我认为,将 enableAck 设置为 false ,并在 Hwi 函数的最末端自行调用它,会对堆栈溢出的可能性产生显著影响。 即使在 Hwi 函数运行后、仍有将在中断上下文中执行的 Hwi 调度器的后一半。
如您所指出的、如果您的掩码设置为 none、则无论 ACK 状态如何、其他组的中断都能够嵌套。 对于同组中断、它将能够在设置 ACK 后执行、因此它将优先于 Hwi。
Whitney