[参考译文] Compiler/TMS320F28069：/tmp Build Error with boot28.inc

我认为 本主题中的讨论 将会有所帮助。

谢谢、此致、

乔治

您需要设置 CCS 源搜索路径以包含库源目录。 这是$(compilerroot)/lib/src、适用于 C2000 6.1.6之后的版本。 这应该自动发生。 用户使用哪个版本的编译器？ (注意：这与 CCS 版本不同。)

谢谢 George、

您知道...我在 boot28.inc 上进行了快速搜索、但没有找到这个线程。

是的、这是他们想要的。 很高兴看到它已经记录在案...便于分享。

再次感谢、
Chris

客户已在其 CCS 源代码搜索中正确添加了$(compilerroot)/lib/src、但仍显示错误。

还有其他想法吗？

Ty、
是的

用户使用哪个版本的编译器？ (注意：这与 CCS 版本不同。)

很抱歉、打算在上一个帖子中包含该内容。  他们告诉我他们正在使用 v6.2.0编译器。  我知道这也是 CCS 版本号、但它在 C2000编译器实际上是6.2的路径中显示。

当然，评论受到欢迎。

感谢考古学家 Indiana Jones！

-cy

6.2.x 分支上直到6.2.4才会出现"lib/sr"目录。 客户需要升级到该版本或更高版本才能自动查看库源代码。

或者、客户可以进入 lib 目录并将 rtssrc.zip 解压到 lib/src 目录中。

明白了！ 好的、那就应该这么做。 听起来像是一个计划。 很抱歉、我在今天早些时候回复该主题时没有看到(版本号)。

谢谢考古学家！

-cy

拱形、

客户正在运行6.2.11 -我假设是接近"十一月"的版本更新-但在单击"调试"后仍然看到相同的错误。  这里还有其他事情吗？

谢谢、

Chris

如果您是指错误"Can't find a source file at /tmp/TI_MKLIBr6S4KF/SRC/boot28.inc (无法在上找到源文件)"、我无法对其进行解释。 C2000编译器版本6.2.11随 lib/src/boot28.inc 一同提供、作为平面文件、因此、如果 CCS 源搜索路径设置正确(这应该是自动的)、用户应该能够在调试器中看到该源文件。 让用户检查文件是否存在于磁盘上、CCS 实际上是为该工程使用6.2.11版、以及 CCS 源代码搜索路径是否包括 lib/src 目录。

如果您是指在杂草中关闭 PC 的错误、我们没有看到任何有助于我们诊断该问题的详细信息。

考古学家

如果他们手动找到缺失的文件…args_main.c 和…boot28.c、则问题就会消失。 请参阅附件。

但仍存在 ILLEGAL_ISR 问题。

还有其他意见吗？  谢谢！

-cy

考古学家

如果他们手动找到缺失的文件…args_main.c 和…boot28.c、则问题就会消失。  请参阅附件。

但仍存在 ILLEGAL_ISR 问题。

感谢您的任何进一步评论！

-cy

好的、那么源代码存在于磁盘上、但似乎发现它的自动方法不起作用？  坦率地说、我认为我无法进一步诊断这个问题。  编译器(C2000版本6.2.11)正在实现其接口的末尾、因此我们在编译器论坛上可能无法再解决该问题了。  如果用户需要解决此问题、我建议在 CCS 论坛中发布新帖子。

至于中断：

1.   用户的程序是否尝试读取 argc 或 argv、main 的参数？
2.   哪个中断由 ILLEGAL_ISR 处理？  查看中断矢量表。

我完全理解并同意您对编译器的看法。 供参考：搜索路径仍然是指6.2.0 lib/src 目录。 它们仅在出现错误"Can't find a source file at /tmp/TI_MKLIBr6S4KF/SRC/boot28.inc (无法在上找到源文件)"后找到6.2.11的 src 目录。 (如果没有新错误，它们可能会将其更改为6.2.11)。

是的、6.2.11和6.2.0 src 目录都存在于磁盘上。

对于中断：
1.不，不是。
非法_ISR 可由 HVLLC-Main 中的任一函数 A0、B0、C0、A1、B1处理。 这是不确定的、他们仍在跟踪它。

谢谢、
是的

考古学家

下面是第一个问题 boot28.inc:的随附屏幕截图

并且...仅为了更正第二个问题(INT)的信息：

由于中断为空、除了 ESTOP0命令和环路中断、因此 ISR 不非法处理任何中断。

再说一次，所有的评论都很受欢迎！

Ty、
是的

关于 CCS 无法找到 RTS 启动例程的源代码的问题...  请参阅此 Wiki 文章中标题为 调试库代码的部分。

谢谢、此致、

乔治

感谢您的分享。  您是否对 ILLEGAL_ISR 错误以及 George 有任何见解？

谢谢、

Chris

当我说"哪个中断由 ISR_ILLEGed 处理"时、我并不意味着程序中的哪个功能由 ISR_ILLEGed 执行、我指的是哪个中断矢量插槽具有值 ISR_ILLEGed。 您已经向我们展示了 PieVectTableInit、它使用值 ISR_ILLEGAL_REGISD 清晰地填充了 PieVectTable 的116个插槽。 这意味着 ISR_INAILLEGAL_IS 是所有116个不同中断的中断处理程序。

您的系统显然已收到 PIE 中断。 我们需要确定哪一个。 有12个 PIEIFR 寄存器、每个寄存器对应 PIE 模块使用的 CPU 中断(INT1−INT12)。 请向我们显示 PIEIFR1至 PIEIFR12的值

请参阅 SPRU078、"TMS320C8x 系统和中断参考指南"

另见 processors.wiki.ti.com/.../Interrupt_Nesting_on_C28x

考古学家

为了继续讨论 ISR_ILLEGAL_issue、我已将来自客户的 INT1值连接到 INT12。

感谢您的意见。  请告诉我您的想法。

-cy

这是 IFR 寄存器。 例如、INT14是一位。 我们需要查看 PIEIFR 寄存器、这些寄存器与 IFR 标志相关、但与 IFR 标志不同。

哎呀、这是我的错。  在这里。  很抱歉。

好的、请注意 PIEIFR3是0x1、PIEIER3是0x9。 这意味着用户只获得 PIE 中断 INT3.1、即(如果我没有弄错) EPWM1 (请参阅 SPRUHM8E 部分的"PIE 通道映射")。 PIE 中断 INT3.1的中断向量时隙为0x0D60。 用户安装了什么中断处理程序来捕获 PIE 中断 INT3.1？ 地址0xD60处的32位值是多少？

考古学家

很抱歉、由于其他一些问题、客户的回复延迟了很长时间。

首先、您是正确的、因为该地址(INT3.1)是指 EPWM1。  他们已经检查了地址0xD60处的32位值、它是32810。  但他们认为这不是导致 ILLEGAL_ISR 的真正原因。  EPWM1在 COUNTER=0时触发事件、但事件标志 ETFLAG (请参阅 ETFRC 排印错误附件)在 EPWM4的子例程中被清除。  在 EPWM4中执行“清除标志”的示例 asm 代码在中进行了注释(我不知道为什么……)。 将 asm 代码放回后、应清除 IFR 和 IER。  此外、您是否认为事件触发中断发生器中可能存在拼写错误(请参阅上一个附件)？

此外，如果他们单击调试工具栏中的“重新启动”，代码将不会陷入 ILLEGAL_ISR 中。  您对此有什么见解吗？

Ty、

是的

----

尊敬的 Chris：

我可以确认这是第二幅图中的一个拼写错误。 下次发布 F2806x TRM 时、修复程序将显示。

CTRU=CMPB 行的值应为110

此致、

Kris

您好、Kris 和所有人、

明白。 感谢您的确认。 但是、即使配置正确(CTRL=CMPB)、客户也会发现、即使在调试模式下重新启动程序、也不会使代码陷阱按预期进入 ILLEGAL_ISR。

有什么想法？

Ty、
是的

Kris 和团队、

我是周五拜访这位客户。 您能在这之前评论一下吗？

谢谢、
Chris

考古学家

非常感谢。 上周五、我们与客户面对面交流、并解释了您的意见。 现在他们都很满意。 案例已关闭。

再次感谢、

是的