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

嗨、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