[参考译文] TMS320F28388D：当 STL_CLA_runPESTMicro () 时触发 CLA1_1 INT False

嗨、Lori、

感谢您的答复。 我将检查我们的应用是否具有您提到的行为。

我还有一个与 CLA 任务触发机制相关的问题。

目前、我们的应用 CLA 任务由每个 50µs 的一个 EPWM 事件触发。 我们观察到一种情况、在执行 pest 几次后、不再触发应用程序 CLA 任务。

在调试期间、我们发现相应的 ePWM 事件触发标志寄存器显示了 INT 标志被置位。

根据我的理解、这可能是因为 EPWM 事件在 PEST 运行时发生、但此时没有处理程序 (CLA 任务或 ISR) 能够为事件提供服务、因此事件仍处于挂起状态。 因此、不再发生后续的 CLA 任务触发。

您能否帮助确认这一理解是否正确？

如果是这种情况、建议采用什么方法来处理这种情况？
例如、我们是否应该在运行 PEST 之前明确禁用 EPWM 事件触发器、或者是否有更好或更推荐的方法？

提前感谢您的帮助。

此致、
Norman

嗨、Lori、

回到原始问题：经过多次调查后、我们找不到任何PIEIER11在 Group 11 ISR 之外修改的代码路径。

然而,我观察到另一个重要的行为。 以免意外触发未寄存和未启用的CLA1_1中断 、该函数STL_CLA_runPESTMicro()返回 0x80 (STL_CLA_FAIL_SPURS_INT)多次 、并且仅在这之后CLA1_1发生意外中断。

然后我仔细看了的行为STL_CLA_runPESTMicro(),这可以总结如下:

1. DINT

2. 禁用所有 CLA 任务

3. 等待所有 CLA 任务完成执行

4. 运行 pest

5. 清除使用的 PIE_O_IFR11 位

6. 读取所有 PIE_O_IFR11 位；如果任何位为非零、则返回 0x80 (STL_CLA_FAIL_SPURS_INT)

在我们的应用中、 CLA 任务 3 行为如下：

• 每个 50µs 都由 EPWM 触发

• 执行其任务逻辑

• 调用CLA_forceSoftwareInterrupt(CLA1_ONLY_BASE, CLA_TASKFLAG_3)以触发 CPU 的 CLA1_3 中断

• 清除 ePWM 事件

• 结束任务

这促使我考虑以下情况：

这可能是可能的 在 CPU 进入DINT内部之前、CLA 任务 3 已开始执行 STL_CLA_runPESTMicro()、和 之后DINT执行 、CLA 任务 3 仍在调用CLA_forceSoftwareInterrupt()。
此时、由于 CPU 中断是全局禁用的 (DINT)、但相应的 PIE_O_IFR11 位仍被置位 是的 没有 ISR 来处理中断 。 因此、当STL_CLA_runPESTMicro()稍后读取时PIE_O_IFR11、它检测到非零值并返回0x80错误。

为了验证该假设、我执行了一个实验 CLA_forceSoftwareInterrupt()在 CLA 任务 3 中注释掉 。 完成此操作后、 0x80CLA1_1不再发生错误和意外中断 。

基于这一结果、我想询问您对两者之间可能存在的关系的看法 CLA_forceSoftwareInterrupt()、 0x80 (STL_CLA_FAIL_SPURS_INT)两种方法 和 意外触发CLA1_1中断 。

任何见解都将非常感谢。

此致、
Norman

CLA 任务是边沿触发的、而不是电平。 我看到了在中断开始后配置 CLA 的情况、在这种情况下、CLA 由于没有看到边沿而不会响应。 在这种情况下、您可以禁用 PWM int 或在适用时手动清除 int 标志。

您好、Norman：

让我想一想,并在一天或两天内回到你身边。  

Lori

嗨、Lori、

非常感谢您的解释和建议—他们非常有帮助。

按照 TI 推荐的程序、我现在通过调用来禁用 CLA3 中断
Interrupt_disable(INT_myCLA03)解决方案 执行STL_CLA_runPESTMicro()、
并通过调用重新启用 IT
Interrupt_enable(INT_myCLA03)之后 STL_CLA_runPESTMicro()完成。

应用此流程后、我不再观察到任何意外情况 CLA1_1 中断 再次发生。
这似乎成功地避免了前面讨论的比赛条件问题。

不过、 0x80 (STL_CLA_FAIL_HYSTERES_INT) 错误仍然存在。 它的行为有些不寻常 — 它既不是纯粹的随机,也不是以固定的利率触发。 根据我的观察,它遵循以下模式:

• STL_CLA_runPESTMicro()每执行一次 12ms

• 大约之后 20,000 人被处决 、
  STL_CLA_FAIL_SPURS_INT (0x80)开始发生 这种情况

  • 大致上 超过 200 次连续出现

• 之后是错误 将完全消失一段时间

• 总执行计数达到大约 90,000 、
  重复相同的行为（再次~200 次连续出现）

• 到目前为止,这种模式似乎 以类似突发的周期性方式重复

换言之、

•  每次执行虫害时都不会发生此错误、并且不是零星的或随机的。

• 此误差 似乎与明确相关  长期执行/累积运行计数 和表现为虚假中断故障的突发

我想问您是否有类似的见解或经验 仅在长期执行后以周期性方式出现的虚假中断行为 。

同时, 我将继续进一步调查这个问题,看看是否能找到更多的线索,如果我发现任何有意义的事情,我会报告回来。

再次感谢您的帮助。

此致、
Norman

您如何检查所有任务是否已完成？ CPU 可以读取 CLA 的 MIRUN 寄存器以检查是否有任何任务正在执行。  

我在   STL_CLA_runPESTMicro() TI 示例中提到的检查所有任务是否已完成、使用了您说的方式。

您好、Norman：

我认为还有另一个竞态条件会导致 STL_CLA_FAIL_BREDERS_INT。  

我是否可以纠正、如果 CLA 3 没有中断 CPU、那么不会发生这种情况？  该标志是否也对应于 CLA 任务 3？

我怀疑有一个中断从 CLA 进入 PIE、并在软件清除 PIEIFR 寄存器后被标记出来。 这可能是一个循环或两个增量从一个“工作“的情况下,清除 PIEIFR. 是否可以尝试在检查 MIRUN 和清除 PIEIFR 之间添加几个循环？

Lori

嗨、Lori、

要回答您的问题：

我是否可以纠正、如果 CLA 3 没有中断 CPU、那么不会发生这种情况？  该标志是否也对应于 CLA 任务 3？

这两个问题的答案都是肯定的。

根据你的建议,我试图在检查 MIRUN 和清除 PIEIFR 之间增加几个周期的延迟,但不幸的是,这并没有改善情况。

然后、我尝试更仔细地查看 TI 库实现、发现了以下行为：

• 完成测试后、该函数清除与该特定测试中使用的 CLA 任务相对应的 PIE_O_IFR11 位。
  
  
• 但是、在杂散中断检查期间、代码会检查 PIE_O_IFR11 中的任何位是否已设置。
  
  
• 如果找到设置了任何位、该函数会报告 0x80 失败 (STL_CLA_FAIL_HYSTRIS_INT)。
  
  

基于此行为、我相信 0x80 故障是在以下情况下发生的：

• 在 STL_CLA_runPESTMicro () 期间、CLA 任务 3 软件在 DINT 之后触发 CPU 中断、从而设置相应的 PIE_O_IFR11 位。
  
  
• 如果当前 PEST 迭代不检查 CLA 任务 3（例如，它检查任务 6）、则该函数仅清除与任务 6 关联的 PIE_O_IFR11 位。
  
  
• 因此、任务 3 设置的 PIE_O_IFR11 位保持置位状态、从而导致 0x80 虚假中断失败。
  
  

为了验证该假设、我进行了一个实验、在该实验中记录了发生 0x80 故障时测试的 CLA 任务。
结果表明、每次触发 0x80 故障时、所检查的任务不是任务 3、我认为这支持上述分析。

我希望你对这一解释的看法。

如果这确实是根本原因、您是否有任何推荐的缓解策略？
例如、在 STL_CLA_runPESTMicro () 内、等到所有 CLA 任务完成执行（通过检查 CLA_O_MIRUN）、然后显式清除 PIE_O_IFR11 中的所有 CLA 相关位一次、然后再执行杂散中断检查是合理的吗？

此外、我想确认 PIE 行为的一个方面：

如果禁用了特定中断（即 PIE_O_IER_x.bit_y = 0）、并且发生了相应的中断事件、是否仍会设置关联的 PIE_O_IFR_x.bit_y？

此致、
Norman

嗨、Lori、

顺便说一下、如果您知道有一个更好的解决方案能够让 CPU 避免丢失 CLA 中断、我很乐意知道。

此致、

Norman

您好、Norman：

我认为这是一个很好的解决方案、因为您的应用可以容忍关闭 CPU 的 CLA 中断。 这比我们试图实现的目标更干净。

此致

Lori