[参考译文] TMS320F28034：更改编译器版本会导致程序异常运行

Yutao、您好！

Unknown 说：

首先，我想知道导致程序异常的问题是否是由编译器的差异引起的。

您是否可以检查这两个函数的反汇编及其函数调用的位置？ 用户可以通过在调试会话中打开"Disassembly"窗口来执行此操作。 然后、我们可以尝试找出导致这种情况发生的原因。

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

 我上传了一个 zip 文件包 、其中包含两个编译器的反汇编窗口文档。我希望它能为您提供一些有用的信息。

此致、

刘玉涛

e2e.ti.com/.../Difference-of-the-disassembly-window.zip

Yutao、您好！

在 xmodemReceive 函数中、您是否能够使用汇编步骤选项在"Disassembly"窗口中逐行执行汇编？ 这样、我们就可以确定它卡在哪个环路中。 另外、如果程序在使用正常步骤选项后消失、您可以使用暂停按钮查看程序卡滞的位置。

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

 当我使用 汇编步骤选项在"Disassembly"窗口中单步执行每个汇编行时、我发现当程序运行到 内存地址代码(0x3FF8CD)时、它不能再进一步停留在那里。

此致、

刘玉涛

Yutao、您好！

是的、 所以程序命中一个指令陷阱(也就是说、一个无效的指令被运行)。 您需要查明代码中的哪些内容会在跳转到 ROM 中的这个位置之前立即执行。 在该指令及其周围会有导致错误的因素、例如跳转到已移动的函数、访问超出范围的数组等。

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

  根据您的建议、我试图找出问题的原因、但我不熟悉汇编语言、这可能会导致我找不到问题的关键。 我上传了一段视频、其中包含了调试过程中每一步的数据信息、我希望您能够帮我看一下、并帮助我找到问题的关键！ 非常感谢！

此致、

刘玉涛

e2e.ti.com/.../20230909_5F00_002822.mp4

尊敬的  Omer Amir：

 该问题可能是由堆栈溢出引起的吗？ 我如何确认这一点？

此致、

刘玉涛

Yutao、您好！

Unknown 说：

问题是否可能是由堆栈溢出引起的？

不,我不相信。 这与代码的编译方式有关。  您可以在反汇编过程中的0：20看到、视频中有一条指令 FFC、 这是一个快速函数调用(有关汇编指令的完整列表、请参阅 C28x 指令集)、它调用了 prologue28.asm 中的函数。 本 prologue28函数有无效指令(描绘为指令代码0xFFFF ITRAP)。 这可能是因为 xmodemReceive 函数出于某些原因不可访问(即处于锁定的安全区域)。 您的程序使用哪种类型的存储器配置？ 您是完全从闪存运行、还是某些函数加载到 RAM？

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

 函数(xmodemReceive) 在闪存中运行、然后在 RAM 中调用一个导致指令缺陷的函数(prologue28.asm)是否可能。 通过比较两个版本的编译器的汇编代码、我们可以看到一些差异。

此致、

刘玉涛

Yutao、您好！

您是否使用了与使用较旧编译器版本的工程相同的链接器命令文件、工程属性和编译配置？ 我想再次检查、因为发生这种问题的少数原因之一是 memcpy 被用来 从闪存加载程序并且代码未正确复制、然后从 RAM 运行程序。 或者有一些链接器命令文件更改、但函数未加载到正确的存储器单元。

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

 除了优化级别(V15.12.3：level=1 speed=3    V20.2.5：level=1 speed=1)和编译器不同外、一切都是相同的。

此致、

刘玉涛

Yutao、您好！

您如何更改编译器？ 您是刚刚更改了"项目属性"中的设置、还是创建了一个新项目？ 如果您刚刚更改了项目属性、我将看到我是否可以将此查询转发给编译器团队、以了解为什么此代码编译方式不同。

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

  是的、 我 只需更改"Project Properties"中的设置。  

此致、

刘玉涛

尊敬的  Omer Amir：

 如果您需要我提供任何材料、请告诉我。 如果您能帮助我找到问题的原因、我将不胜感激。

此致、

刘玉涛

尊敬的  Omer Amir：

我发现了问题的原因。

原因：V20.2.5的编译器将升级期间使用的一些代码打包到一个函数(_prologue_C28x_2)中、该函数存储在闪存(0x3f1c86)中、 以便在升级之前擦除、从而不能在升级期间调用该代码。  但我仍然有一个问题、为什么这个函数内的指令存储在闪存和 RAM 中？

此致、

刘玉涛

Yutao、您好！

您需要查看链接器命令文件以 找到代码的存储位置；如果它是某个库的一部分、您可以查找该库名称。 除了链接器文件中的内容、除非有特定的#pragma 语句、否则我不知道函数的存储器位置是如何指定的。

此致、

阿米尔·奥马尔

编译器专家指出、内存中的位置正被失控代码或类似的东西覆盖 ITRAP (无效指令)。 请找出 ITRAP 指令首次出现的时间、即它们在加载后、执行开始前或执行一段时间后出现在那里？ 您可能会发现导致该存储器被覆盖的原因。

此致、

阿米尔·奥马尔

Yutao、您好！

现在您已经找到导致函数被擦除的原因、应该能够调整存储器分配来防止这种情况的发生。 我将关闭此主题、除非您有进一步的问题。

此致、

阿米尔·奥马尔

尊敬的  Omer Amir：

 感谢您今天耐心地回答问题、这对我非常有帮助、使我能够学习解决问题的新方法。

此致、

刘玉涛

当然、我们始终乐于帮助您。