主题中讨论的其他器件： C2000WARE
工具/软件：TI C/C++编译器
我在 为 TMS320F28379D 控制卡开发闪存应用时使用 C2000编译器的 BINIT 功能遇到了一个奇怪的问题。
我已附上该项目的精简版本。 其中的许多内容来自 C2000ware 通用头文件。
我一直在利用 binit 复制表功能在引导时将闪存的段自动复制到 RAM 中。 到目前为止、它一直运行良好、在这种情况下、我的代码已经增长、它似乎取决于所复制数据的大小。
观察到的行为(使用 C2000 codegen 工具18.1.1、18.1.2)
当我使用调试器进行编程并点击"run"时、一切都正常。 但是、如果我先断电、然后再备份、处理器似乎一直处于复位状态(我检查了引导模式引脚是否设置为 getmode)、并且在连接/未连接调试器的情况下加电时的行为是相同的。 很难调试它的状态、它可能是 ITRAP、也可能卡在引导 ROM 中、不确定。 我确实为 PIE 中的所有矢量分配了一个保留 ISR、如果它到达中断、它会使 LED 闪烁、但我尚未观察到这一点、因此我认为它不是 ITRAP。
明显的权变措施
如果我足够减小 CLA 程序代码大小、此行为将停止、并且我可以多次加电和断电、并且每次启动到闪存应用程序时(通过闪烁 LED 可以看到)。 您可以通过编辑 ClaTasks.cla 并删除所有 _mdebugstop()语句来尝试此操作。 似乎存在某种大小的问题、可能是 binit 例程失败了。 与此处理器中可用于 CLA 代码的0x3000相比、发生这种情况的大小完全不大。 我也不确定这只是与 CLA 代码段相关、这可能会发生在诸如 ramfuncs 之类的其他段中。
如果我使用15.12.7编译器、此行为也会停止(仅在18.1.1和18.1.2中可见)。 我仅测试了这3个编译器版本。
如果我不使用 BINIT 功能、只需将加载/运行变量与 memcpy 一起使用、此行为也会停止。 在项目中、我有两种不同的构建配置。 "DebugBINIT"使用 BINIT 功能。 而"Debug"仅使用加载/运行变量以及 memcpy。
观察结果
奇怪的是、当使用18.1.x 编译器并使用 BINIT 功能以及使用 XDS100v2调试器进行编程时、它在启动后运行良好。 即使我执行暂停、然后复位 CPU、然后重新启动、每次都可以正常运行。 但是、如果我断电、然后进行备份(无论是否连接了调试器)、它都不会引导闪存应用程序。
我发现唯一可行的是不使用 BINIT、不使用15.x.y 编译器或减小 CLA 代码大小。 所有这些似乎都是不相关的，也是奇特的，希望你们能给一些光亮。
