[参考译文] TMS320F28P550SG：触发 TMS320F28P55x 未处理中断

尊敬的 Emily：

这当然是一个奇怪的问题。 我会说、当 IFR.INT8 /和 IER.INT8 被清除时、这是正常现象、因为在将中断从 CPU 处理时、硬件会自动清除这些字段。 PIEIFR8 也应在矢量提取发生后自动清零。 然而,这并没有解释 PIEIER8。 需要检查以下几点：

在未处理的中断中读取这些寄存器时、您能否验证 CCS 中的“Continuous Refresh“按钮是否打开？

您是否还可以在默认 ISR 处理程序中添加 GPIO 切换开关、以验证在独立模式下（未连接调试器）的行为是否相同？

在 SysConfig 中、您能否查看生成的代码并验证它实际上是将配置写入 SCIA 而不是 SCIC？

我应该注意、我要使用相同的 SCI 和中断处理从 TMS320F280049C 移植代码。 据我所知、这两个处理器之间的 SCI 功能/API 是相同的。

是的、以上都是正确的。 这两种器件上的 SCI 模块是相同的。  

此致、

Delaney

您好 Delaney、感谢您回复我。

连续刷新已打开、我已尝试手动刷新、关闭并重新启动 CCS、以确保它不是 CCS 问题。

2.我可以让它在不进行调试的情况下自由运行、并将 GPIO 配置为在虚假中断 88 触发时切换。  

3.是的、我可以确认我已检查生成的 SYSCFG 代码、以确保没有使用其他外设、也没有生成异常。

4.我也注意到,如果我让它继续运行,那么其他的虚假中断就会发生。 我看到中断 40、23、64。 40 和 64 是组 2 和 5 中的第一个中断、23 是用户定义的奇数中断、我们不使用该中断。

我发现器件勘误表中可以解释这个问题。 我已经实施了此处所述的修复、但这不能解决问题。

勘误表 TMS320F28P55x 实时 MCU 器件勘误表器件修订版本 A、0
SPRZ572B–2024 年 4 月–2025 年 2 月修订

人们认为、这些是早期的 UCS、存在问题、因为这仍然是一款相当新的器件。 根据 PARTIDL 寄存器、我的 UC 是一个工程样品。 是否可以从 TI 采购完整生产样片的 UCS 来排除这是否是器件问题？

尊敬的 Emily：

感谢您的答复。 我看不到您链接的勘误表、但它是下面的吗？

如果是这样、这只适用于中断嵌套实现。 您是否在您的应用程序中启用了嵌套？ 如果是、您能给我展示一下您是如何编写 ISR 代码（必须以非常具体的方式完成）吗？

我将查看有关量产样片的问题并返回给您。

此致、

Delaney

对缺乏回应表示歉意。

因此、首先在其余 ISR/UART 配置按压后、我注意到一些关键段代码执行错误。 该代码被两个关键部分 ENTER 呼叫包裹、不需要退出。 解决了此问题、虚假中断问题似乎已经消失。 尽管如此、我还是打算稍后返回此处来确认这种行为、因为似乎确实有一些其他中断被触发而没有原因。

为回应您的最后一个帖子、我们不会实现嵌套中断、但是我特意在勘误表中提到的所有中断的末尾添加了 EDIS。

我提到的勘误表是  SPRZ572B 文档、来自 www.ti.com/.../sprz572b.pdf

尊敬的 Emily：

我会在 1-2 天内回复您。

此致、

Delaney